mysql随机取数据方法
Mysql中哪些场景下会导致使用了索引但索引失效，导致性能变差？
Mysql中哪些场景下会导致使用了索引但索引失效，导致性能变差？
程序员应该都知道，为了提高数据库的查询速度，我们可以对表上的一个字段或者多个字段建立索引，但是有些 SQL 错误的写法，可能会导致索引失效。
01. 查看执行计划
如何判断 SQL 的执行是做了全表扫描还是走了索引，不是凭感觉判断 SQL 执行的快慢，而是要看 SQL 的执行计划；很多工具都提供了查看执行计划的功能，不过最原始的方法，还是通过 explain 进行查看；下面的 SQL，是否使用的索引，一目了然。
1. 没有索引
explain select * from user where gender M
2. 有索引
explain select * from user where name Tom
02. 索引失效
1. 使用 like 时，% 在前面不走索引（在后面可以走索引）；
explain select * from user where name like %om
2. 数据类型出现隐式转化，比如我们这里手机号 mobile 字段设置的是 varchar 类型，但是查询的时候用的是数字，那么就【可能】不走索引。
explain select * from user where mobile 13800000000
3. 在索引字段上使用 not，ltgt，! ；
explain select * from user where mobile ltgt 13800000000
explain select * from user where mobile ! 13800000000
4. 对索引字段上使用函数；
explain select * from user where length(mobile) lt 10
5. 联合索引，如果查询条件不满足最左匹配原则，则不会走索引；
6. or 会使索引失效，尽管 or 左右的条件都有索引；
explain select * from user where name Tom or mobile 13800000000
总之，MySQL 的索引优化和索引失效还是挺复杂的，主要体现在 MySQL 随着版本升级，有一些我们熟知的技巧可能会不再正确，我们现在认为一定会索引失效的 SQL 写法，可能会变成走索引，所以这也是为什么我在上文中，多次用到【可能】会造成索引失效的原因。
我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。
mysql联合索引最左匹配原因？
最左前缀匹配原则
在mysql建立联合索引时会遵循最左前缀匹配的原则，即最左优先，在检索数据时从联合索引的最左边开始匹配，
示例：
对列Gid、列Cid和列Sid建一个联合索引
联合索引 uni_Gid_Cid_SId 实际建立了(Gid)、(Gid,Cid)、(Gid,Cid,SId)三个索引。
插入模拟数据
查询实例：
上面这个查询语句执行时会依照最左前缀匹配原则，检索时会使用索引(Gid,Cid)进行数据匹配。
注意
索引的字段可以是任意顺序的，如：
这两个查询语句都会用到索引(Gid,Cid)，mysql创建联合索引的规则是首先会对联合合索引的最左边的，也就是第一个字段Gid的数据进行排序，在第一个字段的排序基础上，然后再对后面第二个字段Cid进行排序。其实就相当于实现了类似 order by Gid Cid这样一种排序规则。
有人会疑惑第二个查询语句不符合最左前缀匹配：首先可以肯定是两个查询语句都保函索引(Gid,Cid)中的Gid、Cid两个字段，只是顺序不一样，查询条件一样，最后所查询的结果肯定是一样的。既然结果是一样的，到底以何种顺序的查询方式最好呢？此时我们可以借助mysql查询优化器explain，explain会纠正sql语句该以什么样的顺序执行效率最高，最后才生成真正的执行计划。