Details
Minor Description
Applying this trick: http://openquery.com/blog/cache-preloading-mysqld-startup
(I realise this has been superceded by the XtraDB LRU dump/reload stuff - but since the below occurred and appears to identify a bug, it's useful to report anyway)
It's MariaDB 5.2.7
MariaDB [(none)]> SET SESSION group_concat_max_len=100*1024*1024;
|
Query OK, 0 rows affected (0.00 sec)
|
|
|
MariaDB [(none)]> SELECT GROUP_CONCAT(CONCAT('SELECT COUNT(`',column_name,'`) FROM `',table_schema,'`.`',table_name,'` FORCE INDEX (`',index_name,'`)') SEPARATOR ' UNION ALL ') INTO @sql FROM information_schema.statistics WHERE table_schema NOT IN ('information_schema','mysql') AND seq_in_index = 1;
|
Query OK, 1 row affected (0.15 sec)
|
|
|
MariaDB [(none)]> select length(@sql);
|
+--------------+
|
| length(@sql) |
|
+--------------+
|
| 869378 |
|
+--------------+
|
1 row in set (0.00 sec)
|
so far so good, resulting SQL query is only 800K long.
MariaDB [(none)]> PREPARE stmt FROM @sql;
|
ERROR 1064 (42000): memory exhausted near 'INDEX (`PRIMARY`) UNION ALL SELECT COUNT(`id`) FROM `dbname`.`colname' at line 1
|
It appears (thanks HarrisonF) that the parser runs out of memory? We reckon that'd be a bug.
I'm happy to pass along the entire @sql string, but a) it contains customer details (db/table/col names) so it'd have to be in private and b) the SQL wouldn't run on any other server anyway since the parser would find nonexistent dbs/tables/cols and thus never get to the bug.