技术博客
MySQL（InnoDB）中，事务对数据的增删改**必然同步更新所有相关索引**，哪怕事务尚未提交。这不是延迟操作，而是立即发生的物理变更：插入要往B+树里加节点，更新索引列要删旧项+插新项，删除则标记索引条目为待清除。这些变更写入redo log保证持久，同时记录在undo log支撑回滚——也就是说，索引结构在事务生命周期内已被占用、锁定、甚至分裂。
MySQL 在 WHERE 子句中对索引列使用函数（如 UPPER()、DATE()、SUBSTRING()、YEAR() 等），会直接导致该列上的索引无法被用于范围扫描或等值查找——不是“可能失效”，而是“基本必然失效”。
MySQL升级后性能下降，不是小概率事件，而是常见现象。核心原因往往不在版本本身，而在于新旧版本间默认行为、统计信息、执行计划和配置兼容性的隐性变化。重点不是“回退”，而是快速定位变化点并针对性调整。
常见于 AUTOCOMMIT=1 未开启、语句被静默忽略，或 WHERE 条件不匹配却误以为“失败”。先确认是否真没更新：
跨版本升级 MySQL 需谨慎操作，不能直接替换二进制文件或跳过中间大版本（如从 5.6 直接升到 8.0），必须遵循官方推荐路径，重点防范兼容性问题、SQL 行为变化和权限模型调整。
SQL标准是一套由ANSI和ISO共同制定的通用规范，定义了关系型数据库应支持的数据查询、定义、操作和控制语法。它不是某个软件，而是一份“语言说明书”，就像汉语有《现代汉语词典》一样，SQL标准规定了SELECT、CREATE TABLE、JOIN等语句该长什么样、该怎么行为。
MySQL小版本升级和大版本升级的核心区别在于变更范围、兼容性影响、操作方式和风险等级。小版本升级（如 8.0.33 → 8.0.35）本质是修复补丁和小幅优化，基本保持结构与行为一致；大版本升级（如 5.7 → 8.0）则涉及数据字典重构、默认行为变更、废弃功能移除和安全策略收紧，属于结构性演进。
MySQL锁竞争主要发生在高并发写入或长事务场景下，核心优化方向是缩短锁持有时间、降低锁粒度、避免不必要锁，并合理使用索引。关键不在于“完全消除锁”，而在于让锁更快释放、更少冲突。
MySQL行锁等待主要发生在高并发更新同一行数据时，核心优化方向是缩短事务持有锁的时间、减少锁冲突概率、合理设计索引与事务逻辑。
MySQL升级后SQL报错，多数是因为新版本加强了SQL模式校验、废弃了旧语法、或调整了默认行为（比如ONLY_FULL_GROUP_BY启用、STRICT_TRANS_TABLES默认开启、隐式类型转换限制更严等）。直接改SQL往往比调兼容模式更稳妥，但临时适配可结合两者。