技术博客
回表不是错误，而是 InnoDB 的正常行为——当你用非主键索引（比如 INDEX(user_id)）查数据，但又要返回没包含在该索引里的字段（比如 product_detail 或 name），MySQL 就得先从二级索引树里捞出主键 ID，再拿这些 ID 去聚簇索引（也就是主键索引）里逐条找完整行。这相当于一次查询触发两次 B+ 树查找。
MySQL 本身不“实现”学生管理系统，它只负责存储和管理数据；真正实现系统的是应用层（比如 Python/Java/PHP + MySQL），而 MySQL 的角色是设计好表结构、写对 SQL、保障数据准确——这是初级项目能跑起来的底线。
因为 MySQL 在执行 LIMIT 10000, 20 时，仍需扫描前 10000 行数据（即使不返回），再跳过它们，最后取 20 行。数据量大、OFFSET 高时，I/O 和 CPU 开销陡增，索引也未必能完全规避全扫描。
MySQL 中的 filesort 并不是一种特定的排序算法名称，而是 MySQL 优化器对“无法利用索引完成排序”时所触发的**内部排序流程的统称**。它背后实际使用的排序策略取决于数据量、系统配置和字段类型，核心目标是尽可能高效地完成 ORDER BY 或 GROUP BY 所需的排序。
MySQL 在执行一条 SELECT、INSERT 等语句时，会先经过「解析器（Parser）」进行语法分析，这是整个查询生命周期的第一步。它不检查表是否存在、字段有没有权限，只确认 SQL 字符串是否符合 MySQL 自己的语法规则。
频繁创建 MySQL 连接会显著拖慢应用性能，增加数据库服务器负担，还可能触发连接数限制。核心解决思路是复用连接，而非每次请求都新建——关键在于合理使用连接池和规范连接生命周期管理。
MySQL 的 GRANT 语句不支持在单条命令里用逗号写多个用户名，比如 GRANT SELECT ON db.* TO ‘u1’@’%’ , ‘u2’@’%’ 会直接报错 ERROR 1064 (42000)。必须逐条执行，或用脚本批量生成。
因为LEFT JOIN必须保留左表全部记录，即使右表没有匹配项也要补NULL，导致MySQL无法像INNER JOIN那样提前剪枝。执行计划里常看到Using where; Using join buffer，说明它在用缓存做嵌套循环，数据量一大就卡。
数据库表结构设计不是单纯追求理论完美，而是平衡一致性、查询效率和维护成本。范式化能减少冗余、保障数据完整性，反范式化则常用于提升读性能——关键不在“该不该范式”，而在“在什么场景下做何种取舍”。
表锁是“一把锁关整扇门”，行锁是“给门上某把锁只锁住一个抽屉”。这不是粒度粗细的修辞，而是直接影响你线上事务是否排队、接口是否超时的真实机制。