4

我有一个查询在开发服务器上执行的时间比在产品上的时间短（数据库是相同的）。Prod 服务器效率更高（64gb 内存，12 核等）。

这是查询：

SELECT `u`.`id`,
       `u`.`user_login`,
       `u`.`last_name`,
       `u`.`first_name`,
       `r`.`referrals`,
       `pr`.`worker`,
       `rep`.`repurchase`
FROM `ci_users` `u`
LEFT JOIN
  (SELECT `referrer_id`,
          COUNT(user_id) referrals
   FROM ci_referrers
   GROUP BY referrer_id) AS `r` ON `r`.`referrer_id` = `u`.`id`
LEFT JOIN
  (SELECT `user_id`,
          `expire`,
          SUM(`quantity`) worker
   FROM ci_product_11111111111111111
   GROUP BY `user_id`) AS `pr` ON `pr`.`user_id` = `u`.`id`
AND (`pr`.`expire` > '2015-12-10 09:23:45'
     OR `pr`.`expire` IS NULL)
LEFT JOIN `ci_settings` `rep` ON `u`.`id` = `rep`.`id`
ORDER BY `id` ASC LIMIT 100,
                        150;

在开发服务器上有以下解释结果：

   +----+-------------+------------------------------+--------+---------------+-------------+---------+-----------+-------+---------------------------------+
| id | select_type | table                        | type   | possible_keys | key         | key_len | ref       | rows  | Extra                           |
+----+-------------+------------------------------+--------+---------------+-------------+---------+-----------+-------+---------------------------------+
|  1 | PRIMARY     | u                            | index  | NULL          | PRIMARY     | 4       | NULL      |     1 | NULL                            |
|  1 | PRIMARY     | <derived2>                   | ref    | <auto_key0>   | <auto_key0> | 5       | dev1.u.id |    10 | NULL                            |
|  1 | PRIMARY     | <derived3>                   | ref    | <auto_key1>   | <auto_key1> | 5       | dev1.u.id |    15 | Using where                     |
|  1 | PRIMARY     | rep                          | eq_ref | PRIMARY       | PRIMARY     | 4       | dev1.u.id |     1 | NULL                            |
|  3 | DERIVED     | ci_product_11111111111111111 | ALL    | NULL          | NULL        | NULL    | NULL      | 30296 | Using temporary; Using filesort |
|  2 | DERIVED     | ci_referrers                 | ALL    | NULL          | NULL        | NULL    | NULL      | 11503 | Using temporary; Using filesort |
+----+-------------+------------------------------+--------+---------------+-------------+---------+-----------+-------+---------------------------------+

而这个来自产品：

+----+-------------+------------------------------+--------+---------------+---------+---------+--------------+-------+---------------------------------+
| id | select_type | table                        | type   | possible_keys | key     | key_len | ref          | rows  | Extra                           |
+----+-------------+------------------------------+--------+---------------+---------+---------+--------------+-------+---------------------------------+
|  1 | PRIMARY     | u                            | ALL    | NULL          | NULL    | NULL    | NULL         | 10990 |                                 |
|  1 | PRIMARY     | <derived2>                   | ALL    | NULL          | NULL    | NULL    | NULL         |  2628 |                                 |
|  1 | PRIMARY     | <derived3>                   | ALL    | NULL          | NULL    | NULL    | NULL         |  8830 |                                 |
|  1 | PRIMARY     | rep                          | eq_ref | PRIMARY       | PRIMARY | 4       | prod123.u.id |     1 |                                 |
|  3 | DERIVED     | ci_product_11111111111111111 | ALL    | NULL          | NULL    | NULL    | NULL         | 28427 | Using temporary; Using filesort |
|  2 | DERIVED     | ci_referrers                 | ALL    | NULL          | NULL    | NULL    | NULL         | 11837 | Using temporary; Using filesort |
+----+-------------+------------------------------+--------+---------------+---------+---------+--------------+-------+---------------------------------+

prod 服务器上的分析结果向我展示了类似的内容：

............................................
| statistics                     | 0.000030 |
| preparing                      | 0.000026 |
| Creating tmp table             | 0.000037 |
| executing                      | 0.000008 |
| Copying to tmp table           | 5.170296 |
| Sorting result                 | 0.001223 |
| Sending data                   | 0.000133 |
| Waiting for query cache lock   | 0.000005 |
............................................

谷歌搜索了一段时间后，我决定将临时表移动到 RAM 中：

/etc/fstab：

tmpfs /var/tmpfs tmpfs rw,uid=110,gid=115,size=16G,nr_inodes=10k,mode=0700 0 0

目录规则：

drwxrwxrwt  2 mysql mysql   40 Dec 15 13:57 tmpfs

/etc/mysql/my.cnf（玩了很多价值观）：

[client]
port        = 3306
socket      = /var/run/mysqld/mysqld.sock

[mysqld_safe]
socket      = /var/run/mysqld/mysqld.sock
nice        = 0

[mysqld]
user        = mysql
pid-file    = /var/run/mysqld/mysqld.pid
socket      = /var/run/mysqld/mysqld.sock
port        = 3306
basedir     = /usr
datadir     = /var/lib/mysql
tmpdir      = /var/tmpfs
lc-messages-dir = /usr/share/mysql
skip-external-locking
bind-address        = 127.0.0.1
key_buffer      = 16000M
max_allowed_packet  = 16M
thread_stack        = 192K
thread_cache_size       = 150
myisam-recover         = BACKUP
tmp_table_size         = 512M
max_heap_table_size    = 1024M
max_connections        = 100000
table_cache            = 1024
innodb_thread_concurrency = 0
innodb_read_io_threads = 64
innodb_write_io_threads = 64
query_cache_limit   = 1000M
query_cache_size        = 10000M
log_error = /var/log/mysql/error.log
expire_logs_days    = 10
max_binlog_size         = 100M

[mysqldump]
quick
quote-names
max_allowed_packet  = 16M

[mysql]

[isamchk]
key_buffer      = 16M

它不起作用。执行时间仍然相同，大约 5 秒。能否请您回答2个问题：

  1. tmpfs 配置有什么问题？
  2. 为什么服务器上的解释不同，我该如何优化这个查询？（即使不使用 tmpfs；我发现如果最后一个“order by”被删除，查询完成得更快）。

提前致谢。

4

2 回答 2

2

为什么服务器上的解释不同，我该如何优化这个查询？（即使不使用 tmpfs；我发现如果最后一个“order by”被删除，查询完成得更快）。

你说“数据库是一样的”，但从解释输出中你大概是指“模式是一样的”。看起来生产模式中有更多数据？MySQL 根据数据量、索引大小等优化其处理查询的方式。这将解释（在最高级别）为什么您会看到如此巨大的差异。

要查看的解释输出的列是“行”。请注意两个派生表在 dev 中非常小？看起来（您可以在#mysqlfreenode IRC 上询问以确认）MySQL 正在为 dev 中的派生表创建索引，但选择不在生产中创建索引（可能是因为有太多记录？）。

tmpfs 配置有什么问题？

没有什么。:) MySQL 在内存中创建临时表，直到其中的数据量达到一定大小（tmp_table_size），然后才会将临时数据写入磁盘。你可以信任 MySQL 来做到这一点——你不需要在内存中创建一个临时文件系统并将 MySQL 指向那里的所有复杂性和开销...... InnoDB 的关键变量是innodb_buffer_pool_size，我看不到你已经调谐。

网上有很多文档，包括Percona的很多（恕我直言）好东西。（我不隶属于他们，但我曾与他们合作过；如果你能负担得起与他们签订的支持合同 - 就去做吧。他们真的很了解他们的东西。）

我绝对不是调优 MySQL 方面的专家，所以我不会评论您选择的选项，只是说我花了数周时间才阅读和调优——只是为了让 Percona 团队看看它和说“那太好了，但是你错过了这个并且弄错了” - 结果有了明显的改善！

最后我要指出一些其他的东西——索引、模式和查询是主要的。您有两个子查询，我会尝试将它们排除在外，看看是否有帮助。您需要 dev 中可用的代表性数据样本来正确调整查询。（我过去为此使用了只读复制服务器。）我不完全理解您的查询试图做什么，但看起来您可以将这些表加入并分组整体结果。

如果我遗漏了明显的（可能！） - 那么我会考虑单独维护这些子查询中的数据表。我一直INSERT默认使用 SP 来处理 s，因为 DBA 指出您可以在以后以事务安全的方式更轻松地添加此类缓存逻辑。因此，当您插入ci_*表时，还要更新COUNT()数据表（如果您不能排除子查询） - 所以一切都变成了一组索引良好的连接。

于 2015-12-16T15:37:40.170 回答
1

解释表明，在 prod 上，查询不使用 u、derived1、derived2 表上的索引，而在 dev 上使用索引。结果，扫描的行数在 prod 上明显更高。2 个派生表上的索引名称表明它们是由 mysql 动态创建的，利用了mysql v5.6.5 提供的物化派生表优化策略。由于 prod 服务器的说明中没有此类优化，因此 prod 服务器可能具有较早的 mysql 版本。

正如@Satevg 在评论中提供的那样，dev 和 prod 环境具有以下 mysql 版本：

开发：debian 7，Mysql 5.6.28。产品：debian 8，Mysql 5.5.44

mysql 版本的这种细微差异可以解释速度差异，因为开发服务器可以利用物化优化策略，而 prod（仅限 v5.5）不能。

于 2015-12-17T15:34:36.730 回答