«

如何定位,排除和避免MySQL数据库性能问题

时间:2024-1-27 09:34     作者:韩俊     分类: Mysql


做大流量访问级别的web应用开发的项目的时候,我们不得不经常要对应用中的各项功能不断的进行检测,优化以防止应用在关键时刻挂掉。下面作者就如何定位,排除以及避免MySQL数据库性能问题上面发表一些看法。期望能够帮助到同行们能够打造更坚固,更稳定的web应用。

(1)设计表时尽量使用 innodb数据库引擎

建表时,显式指定使用innodb数据库引擎,而不是myisam引擎,myisam引擎的锁是表锁,读锁和写锁是互斥的,读写操作是串行的,锁冲突会严重影响并发.而innodb提供行级锁,能提供较好的并发表现,在我们的业务场景里,也不会引起死锁。

(2)善用数据库索引

对SQL语句中where条件里使用到的字段,合理建立索引。虽然对表建立索引一定程度上会影响写入效率,但在表数据规模不大,写入压力不是特别高的情况下,索引带来的好处是更多的。

(3)合理的分库分表

对数据应合理分库分表,由应用层去动态的选择库和表。MySQL 的 innodb 引擎表虽然理论上可以存储海量的数据,但在我们的业务场景下,数据控制在500w以下会比较合理,追求性能的话,最好控制在200w以下,合理索引。

(4)合理使用缓存

将不常修改的,数据量有限的,又是被密集查询的信息,加载到 cache 里,可以有效的降低数据库压力。在一般的业务场景里,推荐使用开源 memcache,简单而且高效。

(5)善用 explain 命令

项目开发完后,应经常使用 explain 命令检查SQL语句,看是否使用到索引,是否存在 filesort 问题(即没有将 order by 列 设置为索引),以及检查数据检索的行数(rows)是否太大。一般情况下,rows<1000,是在可接受的范围内的。rows在1000~1w之间,在密集并发访问的情况下可能会导致性能问题,但如果不是太频繁的访问(频率低于1分钟一 次),又难再优化的话,可以接受,但需要注意观察rows大于1万时,应慎重考虑SQL的设计,优化SQL,优化db,一般来说不允许频繁运行(频率低于1小时一次)。rows达到10w级别时,坚决不能做为实时运行的SQL。但导数据场合除外,但导数据必须控制好时间, 频度。

explain SQL语句应该是日常开发中的习惯动作,有时explain出来的结果,可能会出于偏离设计的意料之外,所以强烈建议在设计SQL语句时,尤其是稍微复杂的SQL时,一定要在测试环境甚至是实际环境上预先进行 explain 检测。

(6)开启 MySQL 慢查询日志

一般应打开MySQL的慢查询日志(在my.cnf中加入log_slow_queries和long_query_time两个参数),会记录所有查询持续时间超过long_query_time的SQL语句,把这些语句log下来之后,再一一运行 explain 命令进行分析优化。

(7)监视MySQL数据库进程列表

登陆MySQL客户端,使用show processlist查看当前正在运行的SQL语句,如果正在运行的语句太多,且运行时间太长的话,表示MySQL效率有问题。必要的时候可以将对应的进程kill掉。

(8)监视MySQL所占用的系统进程

使用 top,vmstat 等系统命令来检查MySQL进程占用的cpu,内存,以及磁盘IO量来对数据库进行进一步优化。

标签: mysql

热门推荐