摘要：
mysql语句中索引命中规则？在MySQL中，索引命中规则是根据B+树索引结构来确定的。当执行查询时，MySQL会根据查询条件中的列与索引的匹配情况来判断是否命中索引。如果查询条件... mysql语句中索引命中规则？
在MySQL中，索引命中规则是根据B+树索引结构来确定的。当执行查询时，MySQL会根据查询条件中的列与索引的匹配情况来判断是否命中索引。
如果查询条件中的列与索引的最左前缀匹配，那么索引就会被命中。如果查询条件中的列没有与索引的最左前缀匹配，那么索引就不会被命中。
此外，如果查询条件中的列使用了范围查询（如大于、小于等），那么索引也不会被命中。当索引被命中时，MySQL会利用索引快速定位到符合条件的数据行，提高查询效率。
mysql 针对索引加锁怎么理解？
MySQL 中的索引加锁是指在执行查询操作时，MySQL 会自动进行锁定，以确保数据的完整性和一致性。索引加锁可以分为两种类型：
1. 锁定读（Locking Read）：当使用 SELECT 查询语句时，MySQL 会对查询涉及的数据行进行锁定，以防止其他事务对这些数据行进行修改，确保读取到的数据是一致的。
2. 锁定写（Locking Write）：当使用 INSERT、UPDATE、DELETE 等操作语句时，MySQL 会对涉及的索引进行锁定，以防止其他事务对同一索引的数据进行并发操作，确保数据的完整性和一致性。
需要注意的是，MySQL 的加锁机制是自动的，无需手动操作。在执行查询语句或写入操作时，MySQL 会自动判断是否需要进行锁定，并根据事务隔离级别（如 READ COMMITTED、REPEATABLE READ 等）来确定加锁的范围和方式。
索引加锁可以提高数据库的并发性能，减少数据的冲突和竞争，但同时也会对数据库的性能产生一定的影响。因此，在设计数据库表结构和索引时，需要权衡索引的适用性和加锁的开销，以提高系统的整体性能。
在MySQL中，当对某个表进行操作时，如果使用了索引，那么在操作期间会对索引加锁，以保证数据的一致性和完整性。
加锁可以防止其他会话对同一数据进行修改，保证数据的正确性。同时，加锁也可能会导致其他会话的阻塞，因此需要在设计索引时合理设置锁的范围和粒度，以避免不必要的阻塞。总之，理解MySQL中的索引加锁是优化查询性能和保证数据安全的必要手段。
Mysql中哪些场景下会导致使用了索引但索引失效，导致性能变差？
以 Mysql 为例，其中索引 BTree 类型 。以下几种SQL设计会导致虽然使用了索引，但是索引不会生效，即引擎放弃使用索引而进行全表扫描：
- WHERE 子句中使用 != 或 <> 操作符。
- WHERE 子句中对索引列使用 %前缀模糊查询。
- WHERE 子句中对索引列使用 OR 来连接条件。
- WHERE 子句中对索引列使用 NOT IN。
- WHERE 子句中对索引列使用计算、函数、类型转换等操作。
- WHERE 子句中对索引列使用参数。
程序员应该都知道，为了提高数据库的查询速度，我们可以对表上的一个字段或者多个字段建立索引，但是有些 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，<>，!= ；
explain select * from user where mobile <> '13800000000';
explain select * from user where mobile != '13800000000';
4. 对索引字段上使用函数；
explain select * from user where length(mobile) < 10
5. 联合索引，如果查询条件不满足最左匹配原则，则不会走索引；
6. or 会使索引失效，尽管 or 左右的条件都有索引；
explain select * from user where name = 'Tom' or mobile = '13800000000';
总之，MySQL 的索引优化和索引失效还是挺复杂的，主要体现在 MySQL 随着版本升级，有一些我们熟知的技巧可能会不再正确，我们现在认为一定会索引失效的 SQL 写法，可能会变成走索引，所以这也是为什么我在上文中，多次用到【可能】会造成索引失效的原因。
我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。
