MySQL执行SQL语句的过程中，会对涉及的表结构进行多轮检查与访问，这些操作分布在SQL执行的不同阶段，各自承担着不同的作用。整个流程从SQL语句进入MySQL开始，到最终返回执行结果结束，表结构的校验和解析贯穿其中。
SQL执行的整体流程概述
MySQL执行一条SQL语句通常会经历连接器、查询缓存、分析器、优化器、执行器这几个核心阶段，其中分析器、优化器、执行器阶段都会涉及表结构的检查与访问，不同阶段的操作侧重点不同。
分析器阶段的表结构检查
分析器的主要工作是对SQL语句进行词法分析和语法分析，这个阶段会首次检查表结构的相关信息。
词法分析中的表名校验
词法分析会识别出SQL中涉及的表名，此时会检查对应的表是否真实存在于当前数据库中，如果表不存在，会直接返回表不存在的错误，不会进入后续流程。
语法分析中的列名与类型校验
语法分析阶段会进一步检查SQL中使用的列名是否存在于对应的表中，同时会校验列的数据类型是否和SQL操作匹配。比如对字符串类型的列传入数值类型的参数，或者插入的数据长度超过列的定义长度，都会在这个阶段被检测出来。
以下是一段简单的SQL执行报错示例，当表不存在时会直接返回错误：
-- 假设当前数据库中没有test_table这张表 SELECT id FROM test_table; -- 执行后会返回错误：Table 'test_db.test_table' doesn't exist
优化器阶段的表结构访问
优化器的作用是生成SQL语句的最优执行计划，这个阶段会深入访问表结构信息来辅助决策。
索引信息的读取
优化器会读取表的索引结构信息，包括主键索引、普通索引、唯一索引等，判断SQL语句的查询条件是否可以使用索引，选择成本最低的执行路径。比如判断是使用全表扫描还是走索引查询，使用哪个索引效率更高。
统计信息的获取
优化器还会获取表的统计信息，比如表的行数、每个索引的区分度等，这些统计信息也是基于表结构以及表的数据分布计算得到的，会直接影响执行计划的选择。
执行器阶段的表结构校验
执行器阶段是真正执行SQL语句的阶段，这个阶段也会进行表结构相关的最后校验。
权限校验关联表结构
执行器会检查当前用户是否对操作的表有对应的权限，权限信息本身是和表结构关联存储的，校验过程也会访问表的相关元数据。
数据操作的最终适配
如果是插入、更新类的写操作，执行器会再次校验插入或更新的数据是否符合表的约束条件，比如非空约束、唯一约束、外键约束等，这些约束都是表结构定义的一部分。如果不符合约束，会直接返回对应的错误。
以下是一段插入数据违反非空约束的示例：
-- 假设user表有id（主键自增）、name（非空）两个字段 INSERT INTO user (id) VALUES (1); -- 执行后会返回错误：Column 'name' cannot be null
表结构缓存机制
MySQL不会每次执行SQL都重新从磁盘读取表结构，而是会将常用表的表结构元数据缓存在内存中，也就是表缓存。当SQL执行需要访问表结构时，首先会从表缓存中查找，如果缓存中没有，才会从磁盘的系统表空间读取，读取后会放入缓存供后续使用。表结构的变更操作，比如执行ALTER TABLE语句修改表结构，会让对应的表缓存失效，下次访问时会重新加载最新的表结构。
常见相关问题说明
- 修改表结构后未生效：通常是表缓存没有刷新导致的，可以等待缓存自动过期，或者重启MySQL服务强制刷新缓存。
- SQL报错表和列不存在：优先检查分析器阶段的表名、列名拼写是否正确，确认是否在正确的数据库中操作。
- 索引没有生效：可以查看优化器阶段的执行计划，确认优化器是否正确读取了表的索引信息，是否存在索引失效的场景。
总结
MySQL执行SQL时会多次检查并访问表结构，分析器阶段做基础的表和列存在性、类型匹配校验，优化器阶段读取索引和统计信息生成最优执行计划，执行器阶段做权限和约束的最终校验。了解这个流程可以帮助我们更清晰地排查SQL执行过程中的报错问题，也能更好地理解MySQL的执行逻辑，为数据库优化提供参考。