技术博客
回表不是错误，而是 InnoDB 的正常行为——当你用非主键索引（比如 INDEX(user_id)）查数据，但又要返回没包含在该索引里的字段（比如 product_detail 或 name），MySQL 就得先从二级索引树里捞出主键 ID，再拿这些 ID 去聚簇索引（也就是主键索引）里逐条找完整行。这相当于一次查询触发两次 B+ 树查找。
根本原因不是没加索引，而是加了「非唯一二级索引」却没覆盖查询条件，导致 MySQL 退化为间隙锁（Gap Lock）或临键锁（Next-Key Lock），锁住一大片范围。比如 WHERE status = 1，即使 status 有索引，若该值重复率高，InnoDB 仍可能锁住多个索引项及其间隙。
执行 ALTER TABLE t ENGINE=InnoDB 时出现 ERROR 1025 (HY000): Error on rename 或 ERROR 1217 (HY000): Cannot delete or update a parent row，本质是外键约束阻止了引擎切换。MySQL 在修改存储引擎时会重建表，而外键依赖关系会让 DROP + CREATE 流程失败。
在线教育平台的数据库不能直接套用通用 CMS 或电商模型——课程原子性、学习状态强时序、多角色权限交叉、实时互动数据高频写入，这些会立刻暴露简单表结构的缺陷。
执行 INSERT、UPDATE 或 DELETE 时突然报错：ERROR 1205 (40001): Deadlock found when trying to get lock; try restarting transaction 或更常见的是：ERROR 1205 (40001): Lock wait timeout exceeded; try restarting transaction 这说明事务在等某个锁，但等了太久（默认 50 秒），MySQL 主动放弃了。不是死锁，是“干等超时”。
MySQL 8.0 彻底移除了对 Antelope 文件格式的支持，只保留 Barracuda。如果你的 5.7 实例中存在 ROW_FORMAT=COMPACT 或 REDUNDANT 且 FILE_FORMAT=Antelope 的表，在升级后可能报错 Tablespace is missing for table xxx 或直接拒绝加载。
默认情况下，mysqld 只绑定 127.0.0.1，即仅接受本地连接。远程连接失败的第一怀疑对象就是这个配置。
MySQL 本身不“实现”学生管理系统，它只负责存储和管理数据；真正实现系统的是应用层（比如 Python/Java/PHP + MySQL），而 MySQL 的角色是设计好表结构、写对 SQL、保障数据准确——这是初级项目能跑起来的底线。
GTID（Global Transaction Identifier）是 MySQL 5.6+ 引入的全局事务唯一标识，格式为 source_id:transaction_id（如 e1e2f3a4-5678-90ab-cdef-1234567890ab:1）。它替代了传统基于 binlog filename + position 的复制定位方式，核心优势在于：事务在集群中可被唯一识别、无需人工计算位点、支持自动跳过已执行事务、主从切换后仍能准确定位同步起点。
因为 MySQL 在执行 LIMIT 10000, 20 时，仍需扫描前 10000 行数据（即使不返回），再跳过它们，最后取 20 行。数据量大、OFFSET 高时，I/O 和 CPU 开销陡增，索引也未必能完全规避全扫描。