关于SQL开发规范中的那些误区！

在实际SQL应用场景中，SQL优化很重要，之前有开发者因一个SQL难题被困惑了5天5夜。最后只能找相关专家解决。那么，如何优化SQL， 有哪些方案可以选择呢? 1、假设一个表同时有两个索引，idx_int_c1,idx_varchar_c2在:select*from tb where c1=100000 or c2='zhishutang';这个SQL会用到哪个索引?为什么? 大多数人都会选择第一个。其实选择任何一个索引都是错误的。大多数企业都会基于CPU，或者说基于成本优化。如果按照c1来算，两个条件同时满足，它会选择靠前的;如果只能满足一个，它会选择最优的，这是成本优化最核心的原理，选择最适合的状态。从成本优化的角度，应该谁处于空闲，谁就去工作。不一定是运程最快，最重要的是合适。 2、还有，如何判断SQL运行的时候，哪个最好。 比如上图中：一个是不加limit,一个是加了limit，如果整体时间都在1S以下，哪一个最好?很多人会说，肯定是加了limit的好。但是，如何证明? 在优化之前，在终端上做下状态刷新，分别执行这两个SQL。然后对比数据。比如第一个SQL之前是1个Key,后来读了17次。而第二个SQL是从1个Key开始读了4次。这说明第二个动作少，效果更好。所以，判断一个SQL好还是坏，是可以量化的。 3、另外是关于delete优化的问题。之前，有一个人求助，说一个delete语句执行了2个多小时了，还没执行完，能不能把这个SQL回滚?答案是不能，如果你直接回滚，会死得更惨。 评价一个SQL能不能回滚，或者说进行到什么程度?大家都有同样一个感受是，有一个进度条该多好。但事实是，SQL没有。有很多人很暴力，遇到这种情况会直接重启。不重启会卡死，因为它阻塞了后面的任务，SQL不能查询。 笔者建议不要暴力重启，先执行一个“show engine innodb status\G”语句，这样能看到执行时间。如果没有运行状态，就可以Kill掉。 (本文根据资深数据库专家 吴炳锡 老师 在线课堂内容整理。)