analyzer_compatibility_allow_compound_identifiers_in_unflatten_nested
SELECT a.b.c FROM table ARRAY JOIN a 将无法工作，而 SELECT a FROM table 的 Nested a 结果中也不会包含 a.b.c 列。
analyzer_compatibility_allow_non_aggregate_in_having
HAVING 移到 WHERE，而不是抛出 NOT_AN_AGGREGATE。默认行为是按标准进行拒绝；此设置可作为迁移辅助，用于处理那些曾被旧版 analyzer (enable_analyzer = 0) 静默接受的查询。包含聚合、grouping 或非确定性函数的合取项会保留在 HAVING 中。如果任一合取项包含窗口函数或有状态函数 (例如 rowNumberInBlock) ，则整个 HAVING 的此类重写都会被禁用，这与旧版 PredicateExpressionsOptimizer 的行为一致。当 GROUP BY 使用 WITH CUBE、WITH ROLLUP、WITH TOTALS 或 GROUPING SETS 时，该设置同样会被忽略。
analyzer_compatibility_apply_final_to_all_joined_tables
FINAL 修饰符会被错误地同时应用于所有其他参与 JOIN 的表 (适用于支持 FINAL 的引擎，例如 ReplacingMergeTree) 。默认情况下，FINAL 仅应用于其所在的表。若查询依赖旧行为，可启用此设置以保持兼容；建议的修复方法是在每个需要的表上显式指定 FINAL。
可能的值：
- 0 -
FINAL仅应用于指定它的表。 - 1 - JOIN 最左侧表上的
FINAL会应用于所有参与 JOIN 的表。
analyzer_compatibility_join_using_top_level_identifier
SELECT a + 1 AS b FROM t1 JOIN t2 USING (b) 中，JOIN 将根据 t1.a + 1 = t2.b 执行，而不是 t1.b = t2.b) 。还会考虑 SELECT 列表中子表达式上定义的别名 (例如，在 SELECT uniqExact(a + 1 AS b) FROM t1 JOIN t2 USING (b) 中，JOIN 将根据 t1.a + 1 = t2.b 执行)。当匹配的别名定义在 SELECT 列表中的子表达式上而非顶层别名时，将对此查询禁用并行副本。对于发送到远程服务器的查询 (Distributed 表、remote 表函数) ，仅当标识符在远程服务器上完全无法解析时，此类查询才会因异常被拒绝；如果该别名遮蔽了左表中的实际列，远程服务器会改为基于该列执行 JOIN，因此结果可能与本地执行不同。
analyzer_compatibility_multiple_joins_qualify_column_names
FROM 子句包含两个或更多 JOIN (以逗号分隔的表也计入；ARRAY JOIN 不计入) ，analyzer 会按旧版 analyzer 重写多 JOIN 查询时的方式为结果列命名：
- 通过展开
*、<table>.*或COLUMNS('<regexp>')生成的列，名称格式为<alias-or-table>.<column>(限定符优先使用表表达式的别名；若无别名，则使用不含数据库名的表名；否则使用 CTE 名称；未设别名的已连接子查询中的列不加限定符) 。有两类列会保留不带限定符的名称，因为它们属于 JOIN 而非某个单独的表表达式：由ARRAY JOIN生成的列，以及由JOIN ... USING合并的键。因此，SELECT ll.arr或SELECT ll.k等外部引用在这两种形态下无法解析； - 标识符列表形式的
COLUMNS(col1, col2)并非匹配器展开：每一列都严格保留标识符原有的写法，因此COLUMNS(x)生成x，而COLUMNS(a.x)生成a.x； SELECT列表中未使用别名的列引用会严格保留原有写法 (例如，即使x不存在歧义，SELECT a.x生成的列名仍为a.x) 。
enable_analyzer = 1) 。
analyzer_compatibility_prefer_alias_over_subcolumn
b.id 这样的多部分标识符既可能表示别名为 b 的表中的列 id，也可能表示另一列的 Tuple 子列 b.id 时，优先按别名前缀来解析 (即 b 的列 id) 。默认情况下，analyzer 会优先解析为子列。启用此设置可与旧版 analyzer 的解析方式保持一致。