技术博客
MySQL 的 SELECT 权限不包含元数据访问能力。即使用户能查表内容，SHOW CREATE TABLE、DESCRIBE table_name、甚至 INFORMATION_SCHEMA 中对应表的查询，都需要额外的 SELECT 权限（对 information_schema 库）或 SHOW VIEW 权限（如果涉及视图）。
SQL 存储过程的创建与调用本身不难，但写得高效、安全、易维护，需要关注几个关键点：参数设计、执行计划复用、错误处理、权限控制和调用方式选择。
直接说结论：一张 user_addresses 表，必须带 is_default 布尔字段 + user_id 索引，且默认地址只能有一个——这个约束不能靠应用层“自觉”，得用数据库逻辑兜底。
绝大多数新项目应该直接选 InnoDB，除非你明确知道自己的表只读、不更新、且对事务完全无感。MySQL 5.5+ 默认引擎已是 InnoDB，不是偶然——它支持行级锁、外键、ACID 事务、崩溃后自动恢复；而 MyISAM 只有表级锁、无事务、崩溃后可能丢数据或需手动 REPAIR TABLE。
它本质是加行级写锁，但若查询条件没走索引，InnoDB 会退化为表级锁或锁住整个索引范围；更常见的是事务未及时提交，导致锁长期持有。线上曾有服务因一个 FOR UPDATE 查询后忘记 COMMIT，阻塞了后续 200+ 请求。
不能。它只适合结构简单、数据量小（mysqldump + mysql 命令，不处理锁表、主从同步中断、字符集隐式转换、自增 ID 冲突等真实迁移风险。
因为 mysqldump 默认导出的是建表语句 + INSERT，而分区表的 PARTITION BY 子句在目标库可能因版本、存储引擎或参数不兼容导致报错；更关键的是，mysqldump –single-transaction 在读取分区时可能触发元数据锁冲突，造成长时间阻塞。
MySQL 本身不提供后台管理系统，它只是一个数据库服务；所谓“用 MySQL 搭建后台管理系统”，实际是指：用 MySQL 作为数据存储，配合前端 + 后端（如 Node.js、Python、PHP、Java 等）开发一个带增删改查界面的管理后台。
用 partition exchange 实现历史数据归档和在线表无缝切换，核心在于不锁主表、不搬数据、秒级完成。关键不是“怎么交换”，而是“怎么设计分区策略+怎么控制归档边界+怎么验证一致性”。
SQL 子查询嵌套不是“能用就行”，关键在于什么时候该嵌、嵌几层、怎么写才高效又可读。过度嵌套容易导致性能骤降和逻辑混乱，而合理嵌套则能精准表达复杂业务逻辑——比如“查出每个部门工资最高的员工，且该员工入职时间早于部门平均入职时间”。这类需求单靠 JOIN 或 GROUP BY 很难一步到位，子查询嵌套反而更直观、可控。