标签:代码 估计 where search images 需要 查询 百度 问题分析
数据库水位线的概念大家应该都有所了解,以前我个人觉得这个基本上是纯理论的,跟我们实际开发写sql好像没什么关系。但是在解决一次慢sql的过程中遇到了水位线的问题。
问题现象:
功能出现慢查。慢查sql为 DELETE FROM tb_cust_search_task_detail WHERE task_id = 2024;
问题分析:
大家看了这个sql估计第一反应都是数据量太大了所以导致了慢查,而且会员检索确实存在数据量很大的问题。所以第一个冒出来的解决方案就是分批删除。
然后我就看了下大概多少数据量能导致这样的慢查
一个任务下才3万多个明细就能导致删除超过5分钟??当时有点怀疑,不过我还是没有细究,还是按照分批删除敲代码了。
敲完代码当然就是要测试下速度, 在sqladmin里查发现SELECT * FROM tb_cust_search_task_detail WHERE task_id = 2024 LIMIT 10000 居然查不出来,超过30秒了。。。。。
EXPLAIN看下
扫描行数居然近亿了,总量不是才3万多么,也用到索引了,为什么rows值还是这么大??? 然后看了比这个数量多的其他task_id的执行计划都是正常的。。
然后我就各种百度了下,越看越觉得可能高水位线的问题。看了下面的背景大家应该都知道为什么了
(这里说下这个task_id的背景,这个task_id是个周期性任务,每个半小时就会重新检索一遍,然后把之前的全部delete掉,再insert。这样就是做很频繁的delete,insert)
那后面就是要解决怎么降低这个水位线的问题,如果解决不了,就是改成分批删除一样还是慢查。找了DBA一起讨论这个问题,dba给的建议就是让我加个单独的task_id索引,理由单独的索引更好查询更快(可惜后面mysql没有选用这个索引),顺便他做下表重组,降低高水位线。
重组之后的执行计划,就很正常了
问题的解决方案:
1. 提交脚本给dba,让dba进行表重组,解决目前高水位线的问题
2. 针对于周期性的检索任务,不再采用先全部delete,再insert。不然后面还是有高水位线的问题。 新的方式是 :重新检索的数据跟老的对比,该insert的insert,该delete的delete
3. 针对于页面功能重新检索,编辑的地方,需要删除检索明细的(这种删除次数不是很多的)。改成分批删除
如果很频繁的做delete和insert的时候,可能就要考虑下会不会也存在这种隐患问题。
mysql高水位线问题
标签:代码 估计 where search images 需要 查询 百度 问题分析
原文地址:http://www.cnblogs.com/qin-derella/p/6230304.html