我有一个查询，它在开发服务器上执行的时间少于prod上的时间（数据库是相同的）。 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 |
+----+-------------+------------------------------+--------+---------------+-------------+---------+-----------+-------+---------------------------------+
这是来自prod：
+----+-------------+------------------------------+--------+---------------+---------+---------+--------------+-------+---------------------------------+
| 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个问题：
提前致谢。
答案 0 :(得分：2)
为什么解释在服务器上有所不同，我该如何优化此查询？ （甚至没有使用tmpfs;我发现如果最后'命令' 删除后，查询完成得更快。）
你说“数据库是相同的”，但从解释输出你可能意味着“架构是相同的”。看起来生产模式中还有更多的数据？ MySQL根据数据量，索引大小等优化处理查询的方式。这将解释（在最高级别）为什么你会看到如此巨大的差异。
要查看的解释输出列是“行”。注意两个派生表在dev中是如何非常小的？看起来（你可以在freenode IRC上的#mysql中确认）MySQL正在为dev中的派生表创建索引，但是选择不在生产中（可能因为有更多的记录？）。 / p>
tmpfs配置有什么问题？
无。 :) MySQL在内存中创建临时表，直到它们中的数据量在将临时数据写入磁盘之前达到一定大小（tmp_table_size）。您可以信任MySQL来做到这一点 - 您不需要创建在内存中创建临时文件系统并将MySQL指向那里的所有复杂性和开销...... InnoDB的 key 变量是{{1我无法看到你已经调整过。
网上有很多文档，包括很多（恕我直言）good stuff by Percona。 （我不隶属于他们，但我和他们一起工作过;如果你能负担得起他们的支持合同 - 就去做吧。他们真的知道他们的东西。）
我绝对不是调优MySQL的专家，所以我不会对你选择的选项发表评论，只是说我在阅读和调整之前花了几周时间 - 只是为了让Percona团队看起来在它并且说“那很好，但你错过了这个并且弄错了” - 并且结果有了明显的改善！
最后，我会指出其他一些事情 - 索引，架构和查询是主要的。你有两个子查询，我会尝试将这些子查询考虑在内，看看这是否有帮助。您需要dev中提供的代表性数据示例才能正确调整查询。 （我过去曾使用过只读复制服务器。）我不完全了解您的查询尝试做什么，但看起来您可以加入这些表并对整体结果进行分组。
如果我错过了明显的（可能！） - 那么我会考虑分别在这些子查询中维护一个数据表。我总是默认使用SP来处理innodb_buffer_pool_size，因为DBA指出你可以在以后以事务安全的方式更容易地添加这样的缓存逻辑。因此，当您插入INSERT表时，还要更新ci_*数据的表（如果您不能分解子查询） - 所以一切都变成了一个索引良好的连接集。
答案 1 :(得分：1)
解释说明，在prod上，查询不使用u，derived1，derived2表上的索引，而在dev上则执行。结果，扫描的行数明显更高。 2个派生表上的索引名称表明它们是由mysql动态创建的，利用了materialized derived tables优化策略，可以从mysql v5.6.5获得。由于prod服务器的解释中没有这样的优化，prod服务器可能有早期的mysql版本。
作为评论中提供的@Satevg，dev和prod环境具有以下mysql版本：
Dev：debian 7，Mysql 5.6.28。产品：debian 8，Mysql 5.5.44
mysql版本的这种细微差别可以解释速度差异，因为开发服务器可以利用物化优化策略，而prod - 只有v5.5 - 不能。