面对超长SQL语句的解析需求，许多开发者最先想到的是用正则表达式匹配SELECT ... FROM部分。然而实际经验表明——正则表达式在复杂SQL场景下频繁失效。子查询、注释、括号嵌套、优化器提示（hint）以及各类字段别名，都容易导致正则匹配出现偏差。相较而言，借助sqlparse这类语法解析工具是更为可靠的技术方案。它能够精准解析SQL语法树，有效规避贪婪匹配、注释干扰或嵌套层级带来的误判问题。
用正则提取 SELECT ... FROM 语句，切勿依赖“.*”贪婪匹配模式
直接编写 re.search(r"SELECT.*?FROM", sql, re.IGNORECASE | re.DOTALL) 进行匹配？需要谨慎，这种写法极易截取到错误位置。子查询中包含的 SELECT、注释文本里的 SELECT、以及被换行符和括号包裹的 FROM，都可能导致非贪婪匹配提前结束，或遗漏关键字段列表。
更为可靠的处理策略是：首先移除块注释（/*...*/）与行注释（--...），然后定位最外层的 SELECT 起始位置，持续匹配至对应层级的 FROM 结束。具体实施时，推荐采用两步骤方案：
- 借助
sqlparse库进行语法解析（Python）：parsed = sqlparse.parse(sql)[0]，随后遍历parsed.tokens，定位首个类型为sqlparse.tokens.Keyword且值为"SELECT"的节点，再向后持续收集直至遇到同级"FROM"关键词。 - 若无法引入第三方依赖，至少采用非贪婪匹配结合括号计数策略：匹配到
SELECT后逐字符扫描，遇(递增计数、遇)递减计数，同时跳过引号包裹的内容，待括号深度归零且下一个单词为FROM（忽略大小写与空白）时实施截断。
解析嵌套子查询时，为何仅提取最外层 SELECT？
原因十分明确：日常提及的"核心 SELECT 部分"特指最终输出结果的那一层级，既不是 CTE 中的 WITH 子句，也非 IN (SELECT ...) 内部的嵌套查询。若错误地将子查询视为主干，将导致后续字段名解析异常、别名信息丢失，甚至遗漏关键的 JOIN 关联条件。
判定依据并非位置先后，而是语法层级结构：主查询的 SELECT 必然不在任何括号内部（即括号深度为0），且不被 WITH、EXISTS、IN、WHERE 等关键字直接包裹。实践建议如下：
- 利用
sqlparse的flatten与is_group方法判断 token 是否归属于顶层语句。 - 手动计数过程中，在进入
WITH或左括号前记录当前深度；仅当深度回归至0且前一个 token 不是"WITH"、"IN"、"EXISTS"时，才认定该SELECT为有效的主查询。
字段别名、函数调用与 CASE 表达式常导致正则匹配失败
例如 SELECT COUNT(*) AS cnt, UPPER(name) AS uname, CASE WHEN x>0 THEN 'yes' ELSE 'no' END AS flag FROM t 这类SQL语句，若使用简易正则分割字段，会将 CASE 表达式中的 END 误判为语句终止符，或将 AS 之后的字符串错误识别为新字段的起点。
真正能够稳定完成字段拆分的方案，依然是依托语法树进行遍历解析。以 sqlparse 为例：
for item in parsed.tokens: if item.is_group and item.tokens and item.tokens[0].ttype is sqlparse.tokens.Keyword and item.tokens[0].value.upper() == "SELECT": # 取该 group 下所有逗号分隔的子项，再对每个子项 .get_name() 或 .to_unicode()
若坚持使用正则表达式作为后备方案，至少应将字段部分单独提取后处理：先截取 SELECT ... FROM 完整片段，再按逗号进行分割，对每个分段采用括号计数方式跳过内部逗号（例如 COALESCE(a,b), c 中的首个逗号不应作为分割点）。
留意 SQL 方言差异：MySQL 的 `SELECT /*+ USE_INDEX(t) */` 如何处理？
MySQL 与 Oracle 数据库支持优化器提示（hint），其位置在 SELECT 之后、字段列表之前，格式如 SELECT /*+ ... */ col FROM t。这类提示虽不属于字段定义，却是 SELECT 子句的合法构成部分。若直接从 SELECT 后方开始截取，会误将 hint 纳入字段范围；而完全跳过则可能丢失关键的执行计划信息。
应对策略如下：
- 保留 hint 信息：在提取字段之前，先使用正则
r"/*+[^*]**+(?:[^/*][^*]**+)*/"进行匹配并临时存储，再从SELECT之后将其剔除，最后提取字段列表。 - 若仅关注逻辑结构，可统一移除所有 hint（涵盖
/*+*/、/*!40101 ... */等类型），但需注意 MySQL 的条件注释可能影响兼容性判断。 sqlparse默认情况下无法识别 hint，需要手动配置sqlparse.keywords.KEYWORDS_COMMON["/*+"] = sqlparse.tokens.Keyword方能实现正确分组。
没有万能解决方案。SQL语句越复杂，越应当摒弃纯文本处理方式；即便是临时性脚本，也值得花费几分钟安装 sqlparse——否则耗费在正则调试上的时间，足以让查询执行五次以上。
