ITPub博客

复合索引最令人困惑的当属索引列的顺序，不仅依赖于使用该索引的查询，更需考虑排序和分组。前段时候我发了个帖子：where条件顺序和复合索引字段顺序。感兴趣的朋友不妨参与讨论。今天我提个自己的观点。在应用开发阶段，【选择性】是我们首要考虑因素，请看简图：当出现sql性能问题时，你可能需要注意以下几个：1. 随机IO2. 排序(order by)3. 分组(group by or distinct)这时

该篇是SQL优化的第4篇。这里主要表达我的一个观点是：不该存在的索引就该干掉，留着碍事在2014-3-12 15:39:01 -- 15:55:00这段时间内，在某个业务系统我们发现2个问题：1. 数据库存在大量的查询等待2. 服务器的存在较严重的io等待这种现象在数据库中实际也是很常见，就是某个慢查询，始作俑者，执行特马慢，把后面本该很快的查询给堵住，导致系列长查询出现经诊断，我们发

这是MySQL SQL优化的第三篇。公司某个业务系统频繁抛出问题SQL，我们对此类SQL做了基本面统计：此类SQL近期共执行了12次，最长一次花费480秒，最短286秒t1表的rows有90多万，始终会扫描这么多不需要的数据这是由于MySQL查询优化器在处理相关子查询方面存在局限性MySQL总是会将相关的外层表压到子查询中，它认为这可以更高效地查找数据行。这就意味着MySQL先选择对外层表进行

这是MySQL SQL优化分享第2篇，大家都很崇尚MySQL的一个强大分支Percona，真该跟风吗？有些时候，还是原配靠谱，小三不一定给力。我们先看下sar报告：明显地，CPU %idle 非常低，粗大事了。我们的告警邮件里显示，单条SQL执行时间长达 300秒左右。原始SQL非常长，这里就不贴了，但要表述的一个优化技巧是，优化的第一步，就是格式化 SQL  :-)我们看下问题SQL的问题部分：LEFT OU

赶着这几天有些时间，把前段时间优化的几条SQL经验分享并总结下，以飨来者。第一个要分享的是对MyISAM优化limit分页。背景来自公司某个业务系统提供给爬虫抓取数据。基础信息：MySQL版本是5.1，引擎为MyISAM，原始SQL内容大致如下：注：为避免敏感信息，将很多字段变为col，但不影响阅读 :-)     SELECT Aa.* , B.col, B.col, C.col, C.col FROM (SELECT A.col,

当生了病的query来就诊时，如果身为医生的我们"胡庸医乱用虎狼药"不仅于事无补，还浪费了大量的人力和时间成本，甚至会拖垮服务器所以，我们在接受优化一条SQL，第一件事情便是要明白query病在哪里？是IO？是CPU?只有明白瓶颈在哪里，方可对症下药，也才能药到病除而MySQL QUERY Profiler是一个使用非常方便的QUERY诊断工具，5.0引入。5.1GA版嵌入这个工具详细呈现了SQL

在MySQL中ORDER BY按先后顺序有2种实现方式，先走索引无排序，如果不行，则用FILESORT走索引无排序需要满足2个条件：①排序字段和执行计划中所利用INDEX的索引键(或前面几个索引键)完全一致②表访问方式为index、ref或range [注释：explain输出中的Type可看出]最快的排序就是不去排序，这也证明，索引的另一个非常重要的优势：索引能够降低排序成本，而排序涉及到的资源有CPU和内

环境：mysql> select version()\G; *************************** 1. row *************************** version(): 5.5.28          ㈠ 主要应用场景                  RANGE分区主要用于日期列的分区         例如销售类的表，可以根据年份来分区存储销售记录         如下是对sales表进行分区mysql> create table sales(money int

环境：mysql> select version(); +-----------+ | version() | +-----------+ | 5.5.28 | +-----------+ 1 row in set (0.00 sec)          分区是一种表的设计模式                  分区，分而治之，其重点在于高可用（管理），而附属价值才是性能的提高              &n