从Mysql 5.5升级后，Percona 5.7的“发送数据”变慢

Question

将Mysql 5.5升级到Percona 5.7后，应用程序移动非常缓慢。 我无法优化查询，因为是使用应用程序编译的。我唯一能做的就是优化MySQL服务器（或服务器配置）。

我需要提到的是，我看到一些查询返回大量数据（结果为70M），数据目录位于SSD上。 我有32G RAM，但我为Mysql分配了20（60％，因为我们还有其他小型服务）

如果激活高速缓存，我会注意到一个小改进（将不建议使用）

波纹管是我的配置

显示全球状态结果在这里

有人对提高MySQL config /或服务器的性能有什么想法吗？ 我以带说明的SQL为例。 它返回672行数据，但需要30秒（“发送数据”中停留29秒）。

explain select l.idCodeLocation as idLocation, l.txLocation as name, l.radius as radius, l.amLat as lat, l.amLong as lng, g.isin as isin, g.isout as isout, g.onval as onval, m.isGeofenceIn as isGeofenceIn, m.geofenceInTime as geofenceInTime, m.isGeofenceOn as isGeofenceOn, v.idVeh as idveh, v.idPlateVeh as plate, v.idClient as client from sat_geofence g left join sat_clientLocation as l on (g.idLocation=l.idCodeLocation) join sat_geofence_vehicle_mtm as m on (g.idLocation=m.idLocation) join sat_vehicle as v on (m.idVeh=v.idVeh);
+----+-------------+-------+------------+--------+---------------+---------+---------+-------------------+--------+----------+----------------------------------------------------+
| id | select_type | table | partitions | type   | possible_keys | key     | key_len | ref               | rows   | filtered | Extra                                              |
+----+-------------+-------+------------+--------+---------------+---------+---------+-------------------+--------+----------+----------------------------------------------------+
|  1 | SIMPLE      | g     | NULL       | ALL    | idx           | NULL    | NULL    | NULL              |     38 |   100.00 | NULL                                               |
|  1 | SIMPLE      | m     | NULL       | ref    | idx           | idx     | 768     | Stdb.g.idLocation |      5 |   100.00 | Using index condition                              |
|  1 | SIMPLE      | v     | NULL       | eq_ref | PRIMARY       | PRIMARY | 3       | Stdb.m.idVeh      |      1 |   100.00 | Using where                                        |
|  1 | SIMPLE      | l     | NULL       | ALL    | NULL          | NULL    | NULL    | NULL              | 116952 |   100.00 | Using where; Using join buffer (Block Nested Loop) |
+----+-------------+-------+------------+--------+---------------+---------+---------+-------------------+--------+----------+----------------------------------------------------+

我在这里放置的表格结构： https : //gist.github.com/costyoancea/deee560f9c94aa2463162d7ce0556392

谢谢，科斯蒂

Answer 1

group_concat_max_len = 18446744073709565  -- dangerously large.

请提供SHOW GLOBAL STATUS以帮助进行调优分析。 你有多少RAM？

即使您无法更改查询，也请向我们显示查询。 我们也许可以建议一个有帮助的索引。

Answer 2

您正在丢失m.idVeh上的索引。 m个引用sat_geofence_vehicle_mtm。 请在“第一”位置添加其他简单索引。 要获得调优帮助，请查看我的个人资料，网络个人资料以获取联系信息。 并在“商店”页面上查看我的评论。

Answer 3

Linux ulimit -a限制的建议

ulimit -n 65536       to increase Open File limit from 1024

要使该值在Linux关闭/重新启动后仍然存在，请查看以下内容，

https://glassonionblog.wordpress.com/2013/01/27/increase-ulimit-and-file-descriptors-limit/

您的详细信息可能因操作系统版本而略有不同。

每秒速率= RPS建议为my.cnf [mysqld]部分考虑

join_buffer_size=128K  # from 128M for a more reasonable RAM request per connection
sort_buffer_size=2M  # from ~256M for a more reasonable RAM request per connection
innodb_lru_scan_depth=100  # from 1024 to reduce CPU cycles used every SECOND
innodb_flushing_avg_loops=5  # from 30 to reduce innodb_buffer_pool_pages_dirty 5,692
table_open_cache=10000  # from 4096 to reduce opened_tables RPHr 40,456 
open_table_definitions=10000  # from 400 to reduce opened_table_definitions RPHr 21,459
thread_cache_size=100  # from 14 to reduce threads_created from 64

请期待7天后在我的网站上发布您的反馈和评论。