MySQL作为最流行的关系型数据库之一，在各类业务系统中被广泛应用，但由于其部分特性的实现逻辑比较隐蔽，很多开发者会在使用过程中产生认知偏差，这些偏差往往会引发意想不到的问题。
误区一：MyISAM也支持事务
很多刚接触MySQL的开发者会误以为所有存储引擎都支持事务，实际上MyISAM引擎是不支持事务的。事务的ACID特性只有InnoDB这类支持事务的存储引擎才能实现，使用MyISAM执行多条写操作时，如果中间出现异常，已经执行的操作无法回滚。
我们可以通过简单的测试验证这一点，首先创建两个不同引擎的表：
-- 创建MyISAM引擎的表
CREATE TABLE test_myisam (
id INT PRIMARY KEY,
name VARCHAR(20)
) ENGINE=MyISAM;
-- 创建InnoDB引擎的表
CREATE TABLE test_innodb (
id INT PRIMARY KEY,
name VARCHAR(20)
) ENGINE=InnoDB;
接着分别向两个表插入数据并尝试回滚：
-- 测试MyISAM表的事务 START TRANSACTION; INSERT INTO test_myisam VALUES (1, 'test1'); ROLLBACK; -- 查询会发现数据已经插入，无法回滚 SELECT * FROM test_myisam; -- 测试InnoDB表的事务 START TRANSACTION; INSERT INTO test_innodb VALUES (1, 'test1'); ROLLBACK; -- 查询会发现数据不存在，回滚成功 SELECT * FROM test_innodb;
误区二：只要用了索引查询就一定快
不少开发者认为给查询字段加了索引，查询性能就一定会提升，实际上索引是否生效、能否提升性能还和很多因素有关。比如索引字段参与函数运算、使用LIKE以通配符开头、查询条件类型不匹配等情况，都会导致索引失效。
以下是一个索引失效的常见场景示例：
-- 给name字段创建普通索引 CREATE INDEX idx_name ON test_innodb(name); -- 以下查询不会使用索引，因为对索引字段做了函数运算 SELECT * FROM test_innodb WHERE LEFT(name, 3) = 'abc'; -- 以下查询会使用索引 SELECT * FROM test_innodb WHERE name LIKE 'abc%'; -- 以下查询不会使用索引，因为LIKE以通配符开头 SELECT * FROM test_innodb WHERE name LIKE '%abc';
另外如果查询需要返回表中大部分数据，全表扫描的效率反而比走索引更高，此时MySQL优化器会自动选择全表扫描，不会使用索引。
误区三：读操作不会加锁
很多人觉得只有写操作才会触发锁机制，读操作完全不会加锁，这其实是不准确的。在MySQL的InnoDB引擎中，普通的SELECT查询是快照读，不会加锁，但如果使用SELECT ... FOR UPDATE或者SELECT ... LOCK IN SHARE MODE，就会分别加排他锁和共享锁。
我们可以通过两个会话模拟加锁的场景：
-- 会话1执行，给id=1的行加排他锁 START TRANSACTION; SELECT * FROM test_innodb WHERE id = 1 FOR UPDATE; -- 会话2执行，尝试给同一行加排他锁，会被阻塞直到会话1提交 START TRANSACTION; SELECT * FROM test_innodb WHERE id = 1 FOR UPDATE;
除此之外，InnoDB的MVCC机制下，快照读虽然不加锁，但写操作还是会加行锁，避免不同事务同时修改同一行数据产生冲突。
误区四：唯一索引比普通索引更占空间
有部分开发者认为唯一索引需要额外存储唯一性校验的信息，所以比普通索引更占存储空间，实际上在InnoDB中，唯一索引和普通索引的叶子节点结构基本一致，唯一索引只是多了一层唯一性约束的校验逻辑，存储空间的差异几乎可以忽略。
两者的核心差异在于查询和更新的性能：如果是等值查询，唯一索引找到第一个满足条件的记录就会停止扫描，普通索引还需要继续查找下一个记录判断是否满足；如果是更新操作，普通索引可以使用change buffer优化，唯一索引因为要校验唯一性无法使用change buffer，更新性能会稍差一些。
误区五：自增主键一定不会重复
默认情况下MySQL的自增主键是递增的，不会出现重复，但在一些特殊场景下还是可能产生重复值。比如手动修改自增起始值、主从复制场景下主库宕机后从库切换、批量插入时指定了自增字段的值等情况，都可能导致自增主键重复。
如果需要保证主键绝对唯一，除了自增主键之外，还可以结合业务规则设计分布式ID，避免单点自增主键可能出现的问题。
总结
以上这些误区都是MySQL使用过程中非常常见的，很多问题的根源都是对MySQL的底层实现逻辑不够了解。在实际开发中，遇到不确定的特性可以先通过简单的测试验证，同时多关注MySQL的官方文档，避免因为认知偏差引发线上问题。如果对事务、索引、锁机制这些核心特性有更深入的理解，也能更合理地设计表结构和查询语句，提升系统的稳定性和性能。