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

时间:2018-11-26 08:32:49

标签: mysql database performance upgrade percona

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

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

如果激活缓存(将会弃用),我会注意到一个小改进

Bellow is my config

SHOW GLOBAL STATUS result is here

有人知道对MySQL配置或服务器进行哪些改进以提高性能吗? 我以带说明的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

谢谢, 科斯蒂

3 个答案:

答案 0 :(得分:0)

group_concat_max_len = 18446744073709565  -- dangerously large.

请提供SHOW GLOBAL STATUS以帮助进行调谐分析。你有多少内存?

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

答案 1 :(得分:0)

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

答案 2 :(得分:0)

您的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天后在我的网站上发布您的反馈和评论。

相关问题