Ivan Korenkov added a comment - 2017-06-06 20:29 Сейчас на сервер практически нет прихода данных, но началось кеширование, которое строит отчеты по всем пришедшим за предыдущие сутки данным. Роста нет.

Elena Stepanova added a comment - 2017-06-08 22:43 Simplified test case: --let $n= 1000000   CREATE TABLE t1 (a INT ); INSERT INTO t1 VALUES (1); CREATE TABLE t2 (b INT ); CREATE TRIGGER tr AFTER UPDATE ON t1 FOR EACH ROW SELECT ( SELECT b FROM t2) INTO @x;   --disable_query_log --echo # Running $n queries while ($n) { UPDATE t1 SET a = 2; --dec $n } --enable_query_log   DROP TABLE t1,t2; release PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 25926 elenst 20 0 1.175t 1.045g 14516 S 99.5 6.7 5:46.77 mysqld debug PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 27115 elenst 20 0 16.412g 0.015t 2716 S 49.4 95.2 0:11.61 mysqld Trigger and subquery from a table appear to be important here. Without the trigger the same query executed the same number of times doesn't cause any memory consumption growth; without the subquery the same trigger also works fine. Not reproducible on 10.1.

Sergei Golubchik added a comment - 2017-06-09 12:20 - edited igor , this is caused by your commit 82cb35be11 : commit 82cb35be11c Author: Igor Babaev <igor@askmonty.org> Date: Wed Mar 23 16:09:58 2016 -0700   Changed the base class for Item_window_func from Item_result_field to Item_func_or_sum. Implemented method update_used_tables for class Item_findow_func. Added the flag Item::with_window_func. Made sure that window functions could be used only in SELECT list and ORDER BY clause. Added test cases that checked different illegal placements of window functions. In particular, by this change: sql/sql_select.cc 804   805 thd->lex->current_select->parsing_place= SELECT_LIST; 806 if (setup_fields(thd, ref_ptrs, fields_list, MARK_COLUMNS_READ, 807 &all_fields, 1)) 808 DBUG_RETURN(-1); 809 thd->lex->current_select->parsing_place= save_place; 810 In this bug, trigger invokes Item_singlerow_subselect::fix_length_and_dec() which invokes subselect_single_select_engine::fix_length_and_dec() , then subselect_engine::set_row() and Item_cache::get_cache() . The latter creates a new Item . And the Item constructor counts all items in the SELECT and HAVING clauses: sql/item.cc 495 enum_parsing_place place= 496 thd->lex->current_select->parsing_place; 497 if (place == SELECT_LIST || place == IN_HAVING) 498 thd->lex->current_select->select_n_having_items++; With your change thd->lex->current_select->select_n_having_items is increased for every trigger invocation, and st_select_lex::setup_ref_array() will allocate larger and larger arrays every time.

Igor Babaev (Inactive) added a comment - 2017-06-11 04:22 The fix for this bug was pushed into the 10.2 tree.

Elena Stepanova added a comment - 2017-06-20 16:41 - edited For future reference, stored procedures were also affected (it was also fixed): CREATE TABLE t2 (b INT );   --delimiter $ CREATE PROCEDURE pr() BEGIN DECLARE n INT DEFAULT 0; WHILE n < 100000 DO SELECT ( SELECT b FROM t2) INTO @x; SET n = n+1; END WHILE; END $ --delimiter ; CALL pr(); DROP PROCEDURE pr; DROP TABLE t2; Also, there could be a scenario without an obvious subquery in the SELECT list: CREATE TABLE t2 (b INT ); CREATE VIEW v2 AS SELECT * FROM t2;   --delimiter $ CREATE PROCEDURE pr() BEGIN DECLARE n INT DEFAULT 0; WHILE n < 100000 DO SELECT b FROM v2 INTO @x; SET n = n+1; END WHILE; END $ --delimiter ; CALL pr(); DROP PROCEDURE pr; DROP VIEW v2; DROP TABLE t2; Prepared statements which are re-executed multiple times also triggered the same problem: CREATE TABLE t2 (b INT ); CREATE VIEW v2 AS SELECT * FROM t2; PREPARE stmt FROM "SELECT b FROM v2" ;   --let $n= 100000 while ($n) { EXECUTE stmt; --dec $n }   DROP VIEW v2; DROP TABLE t2;