Question

有些查询会保留＆＃34;统计信息＆＃34;在我的Google Cloud SQL数据库中长期存在状态。（MySQL 5.5）

在this post之后，我将optimizer_search_depth更改为0.但是有些查询的统计时间仍然很长。

> select @@optimizer_search_depth;
+--------------------------+
| @@optimizer_search_depth |
+--------------------------+
|                        0 |
+--------------------------+

> show processlist;
+----+------+-----------+------+---------+------+------------+-----------------+
| Id | User | Host      | db   | Command | Time | State      | Info            |
+----+------+-----------+------+---------+------+------------+-----------------+
|  4 | root | localhost | mydb | Query   |   84 | statistics | SELECT * FROM ..|

表格和计数如下。

> describe mytable;
+----------+---------------+------+-----+---------------------+-----------------------------+
| Field    | Type          | Null | Key | Default             | Extra                       |
+----------+---------------+------+-----+---------------------+-----------------------------+
| col1     | varchar(50)   | NO   | PRI | NULL                |                             |
| col2     | varchar(50)   | NO   | PRI | NULL                |                             |
| col3     | decimal(15,4) | NO   |     | NULL                |                             |
| col4     | decimal(15,4) | NO   |     | NULL                |                             |
| col5     | decimal(15,4) | NO   |     | NULL                |                             |
| col6     | decimal(15,4) | NO   |     | NULL                |                             |
| col7     | varchar(50)   | YES  |     | NULL                |                             |
| col8     | decimal(15,4) | NO   |     | NULL                |                             |
| col9     | decimal(15,4) | NO   |     | NULL                |                             |
| col10    | varchar(8)    | NO   |     | NULL                |                             |
| col11    | varchar(30)   | NO   |     | NULL                |                             |
| col12    | timestamp     | NO   |     | 0000-00-00 00:00:00 |                             |
| col13    | timestamp     | NO   |     | CURRENT_TIMESTAMP   | on update CURRENT_TIMESTAMP |
| col14    | int(11)       | NO   |     | NULL                |                             |
+----------+---------------+------+-----+---------------------+-----------------------------+

> select count(*) from mytable;
+----------+
| count(*) |
+----------+
|   852304 |
+----------+

查询是这样的。

SELECT * FROM mytable WHERE 
((col1 = 'FFP60003' AND col2 = '360' ) OR 
(col1 = 'FIU51001' AND col2 = '210' ) OR 
(col1 = 'FIU51003' AND col2 = '360' ) OR 
(col1 = 'FPC60001' AND col2 = '240' ) OR 
(col1 = 'SLU50006' AND col2 = '360' ) OR 
... (about 2000-3000 and/or) ...
(col1 = '89969' AND col2 = '270' ) ) AND col14 > 0

如上所示，查询很长。我认为这是长统计状态的原因，但我的应用程序需要这种类型的查询。

如何避免长统计问题？

[更新]

SHOW CREATE TABLE和SHOW VARIABLES LIKE '%buffer%'如下所示。

> show create table mytable\G
*************************** 1. row ***************************
       Table: mytable
Create Table: CREATE TABLE `mytable` (
  `col1` varchar(50) NOT NULL COMMENT 'col1',
  `col2` varchar(50) NOT NULL COMMENT 'col2',
  `col3` decimal(15,4) NOT NULL COMMENT 'col3',
  `col4` decimal(15,4) NOT NULL COMMENT 'col4',
  `col5` decimal(15,4) NOT NULL COMMENT 'col5',
  `col6` decimal(15,4) NOT NULL COMMENT 'col6',
  `col7` varchar(50) DEFAULT NULL COMMENT 'col7',
  `col8` decimal(15,4) NOT NULL COMMENT 'col8',
  `col9` decimal(15,4) NOT NULL COMMENT 'col9',
  `col10` varchar(8) NOT NULL COMMENT 'col10',
  `col11` varchar(30) NOT NULL COMMENT 'col11',
  `col12` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00' COMMENT 'col12',
  `col13` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 'col13',
  `col14` int(11) NOT NULL COMMENT 'col14',
  PRIMARY KEY (`col1`,`col2`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

 > SHOW VARIABLES LIKE '%buffer%';
+------------------------------+-----------+
| Variable_name                | Value     |
+------------------------------+-----------+
| bulk_insert_buffer_size      | 8388608   |
| innodb_buffer_pool_instances | 1         |
| innodb_buffer_pool_size      | 805306368 |
| innodb_change_buffering      | all       |
| innodb_log_buffer_size       | 8388608   |
| join_buffer_size             | 131072    |
| key_buffer_size              | 8388608   |
| myisam_sort_buffer_size      | 8388608   |
| net_buffer_length            | 16384     |
| preload_buffer_size          | 32768     |
| read_buffer_size             | 131072    |
| read_rnd_buffer_size         | 262144    |
| sort_buffer_size             | 2097152   |
| sql_buffer_result            | OFF       |
+------------------------------+-----------+

Answer 1

在1GB服务器中，没有innodb_buffer_pool_size大于200M。将其设置为800M将导致交换。 MySQL希望它的缓存能够保留在RAM中;当它们被交换到磁盘时，性能会受到极大的影响。

您的表可能很大，可以完全缓存。所以，＆＃34;表扫描＆＃34;会破坏缓存，使缓存无效，查询将以磁盘速度运行。要么找到一种方法来避免这样的查询，要么获得更多的RAM。

查询保持＆＃34;统计＆＃34;在Google Cloud SQL中长期存在状态（MySQL 5.5）

1 个答案: