在 MySQL 中，锁的行为和效率确实与索引紧密相关，但并非所有的锁都直接“加在索引上”。MySQL 使用多种类型的锁来管理对数据库资源的并发访问，包括表锁和行锁。这里的关键点在于，当使用支持行级锁的存储引擎（如 InnoDB）时，行锁通常是基于索引来实现的，特别是在进行 SELECT … FOR UPDATE 或 UPDATE/DELETE 语句时。

索引与锁的关系
1、基于索引的行锁：
当查询条件能够利用索引时，MySQL 会尽量使用索引来定位需要加锁的行，这样可以减少锁的粒度，提高并发性能。如果查询条件无法利用索引（比如全表扫描），则可能退化为表锁或者对更多行加锁，这会增加锁的竞争，降低并发性能。
2、没有索引的情况：
在 RC（读已提交）隔离级别下：如果表上没有索引，MySQL 可能会进行全表扫描来查找和锁定相关行。这意味着即使查询只影响表中的少数几行，也可能导致整个表被锁定（虽然实际上不是表锁，但效果类似，因为锁定了大量行）。此外，由于 RC 级别下每次读取都会设置新的快照，所以不同的事务可能会看到不同的数据版本。
在 RR（可重复读）隔离级别下：MySQL 使用多版本并发控制（MVCC）来避免在读取时加锁。在 RR 级别下，事务开始后第一次读取数据时会建立一个快照，之后的所有读取操作都会基于这个快照进行，因此即使在事务执行期间数据被其他事务修改，当前事务也看不到这些修改。但是，当执行 UPDATE 或 DELETE 操作时，仍然需要锁定相关行。如果表上没有索引，同样可能会导致大量行被锁定。

索引对于 MySQL 的行级锁性能至关重要。使用索引可以减少锁的粒度，提高并发性能。
在没有索引的情况下，MySQL 可能会进行全表扫描，这可能会导致更多的行被锁定，从而降低并发性能。
无论是在 RC 还是 RR 隔离级别下，没有索引的表在更新或删除操作时都可能面临性能问题。
因此，为了提高数据库的并发性能，建议为经常作为查询条件的列添加索引。

来源网络