RELATEED CONSULTING
相关咨询
选择下列产品马上在线沟通
服务时间:9:30-18:00
你可能遇到了下面的问题
关闭右侧工具栏
MySQL服务维护笔记-2
  • 作者:zhaozj
  • 发表时间:2020-12-23 11:01
  • 来源:未知

[天极网]

仔细的检查应用的索引设计:可以在服务启动参数中加入 --log-slow-queries[=file]用于跟踪分析应用瓶颈,对于跟踪服务瓶颈最简单的方法就是用MySQL的status查看MySQL服务的运行统计和show processlist来查看当前服务中正在运行的SQL,如果某个SQL经常出现在PROCESS LIST中,一.有可能被查询的此时非常多,二.里面有影响查询的字段没有索引,三.返回的结果数过多数据库正在排序(SORTING);所以做一个脚本:比如每2秒运行以下show processlist;把结果输出到文件中,看到底是什么查询在吃CPU。   全文检索:如果相应字段没有做全文索引的话,全文检索将是一个非常消耗CPU的功能,因为全文检索是用不上一般数据库的索引的,所以要进行相应字段记录遍历。关于全文索引可以参考一下基于Java的全文索引引擎lucene的介绍。   前台应用的记录缓存:比如一个经常使用数据库认证,如果需要有更新用户最后登陆时间的操作,最好记录更新后就把用户放到一个缓存中(设置2个小时后过期),这样如果用户在2个小时内再次使用到登陆,就直接从缓存里认证,避免了过于频繁的数据库操作。   查询优先的表应该尽可能为where和order by字句中的字段加上索引,数据库更新插入优先的应用索引越少越好。   总之:对于任何数据库单表记录超过100万条优化都是比较困难的,关键是要把应用能够转化成数据库比较擅长的数据上限内。也就是把复杂需求简化成比较成熟的解决方案内。   一次优化实战   以下例子是对一个论坛应用进行的优化:   用Webalizer代替了原来的通过数据库的统计。   首先通过TOP命令查看MySQL服务的CPU占用左右80%和内存占用:10M,说明数据库的索引缓存已经用完了,修改启动参数,增加了-O key_buffer=32M,过一段时间等数据库稳定后看的内存占用是否达到上限。最后将缓存一直增加到64M,数据库缓存才基本能充分使用。对于一个数据库应用来说,把内存给数据库比给WEB服务实用的多,因为MySQL查询速度的提高能加快web应用从而节省并发的WEB服务所占用的内存资源。   用show processlist;统计经常出现的SQL:   每分钟运行一次show processlist并记录日志:   * * * * * (/home/mysql/bin/mysql -uuser -ppassword < /home/chedong/show_processlist.sql >> /home/chedong/mysql_processlist.log)   show_processlist.sql里就一句:   show processlist;   比如可以从日志中将包含where的字句过滤出来:   grep where mysql_processlist.log   如果发现有死锁,一定要重新审视一下数据库设计了,对于一般情况:查询速度很慢,就将SQL where字句中没有索引的字段加上索引,如果是排序慢就将order by字句中没有索引的字段加上。对于有%like%的查询,考虑以后禁用和使用全文索引加速。   还是根据show processlist;看经常有那些数据库被频繁使用,考虑将数据库拆分到其他服务端口上。   MSSQL到MySQL的数据迁移:ACCESS+MySQL ODBC Driver   在以前的几次数据迁移实践过程中,我发现最简便的数据迁移过程并不是通过专业的数据库迁移工具,也不是MSSQL自身的DTS进行数据迁移(迁移过程中间会有很多表出错误警告),但通过将MSSQL数据库通过ACCESS获取外部数据导入到数据库中,然后用ACCESS的表==>右键==>导出,制定ODBC,通过MySQL的DSN将数据导出。这样迁移大部分数据都会非常顺利,如果导出的表有索引问题,还会出添加索引提示(DTS就不行),然后剩余的工作就是在MySQL中设计字段对应的SQL脚本了。