# 代码审查报告

**文件:** `data\demo-sqlfluff\src\05_layout.sql`
**语言:** sql
**耗时:** 176.0s
**分析工具:** sqlfluff

---

总计: 16 | 错误: 12 | 警告: 3 | 建议: 1

静态分析 · 12 个问题

- 🔴 `sqlfluff:LT01` L2
  第2行：'*' 前应只有单个空格，实际有 2 个空格。
  建议: 删除 `SELECT` 与 `*` 之间的一个空格，改为 `SELECT * FROM my_table;`。
- 🔴 `sqlfluff:LT02` L5
  第5行：该行不应有缩进。
  建议: 删除第5行行首的 4 个空格，使 `SELECT` 顶格书写。
- 🔴 `sqlfluff:LT05` L13
  第13行：行太长（95 个字符超过 80 上限）。
  建议: 建议缩短该列名，或在 sqlfluff 配置中调整 `max_line_length`；如果这是演示代码，也可以在该行使用 `-- noqa: LT05` 忽略此规则。
- 🔴 `sqlfluff:LT01` L19
  第19行：左括号 '(' 前存在多余空白。
  建议: 删除 `SUM` 与 `(` 之间的空格，改为 `SUM(amount)`。
- 🔴 `sqlfluff:LT06` L19
  第19行：函数名 `SUM` 后面未紧接左括号。
  建议: 将 `SUM (amount)` 改为 `SUM(amount)`，函数名与左括号之间不要留空格。
- 🔴 `sqlfluff:LT02` L25
  第25行：')' 前应换行且不应有缩进。
  建议: 把 `)` 移到下一行并顶格，即写成：
`    SELECT id FROM my_table
)`。
- 🔴 `sqlfluff:LT07` L25
  第25行：WITH 子句的右括号应单独另起一行。
  建议: 将 WITH 子句的 `)` 放到 `SELECT id FROM my_table` 之后的独立行，且行首不要缩进。
- 🔴 `sqlfluff:LT08` L26
  第26行：CTE 闭括号之后缺少空行。
  建议: 在 `)` 与 `SELECT * FROM cte;` 之间插入一个空行。
- 🔴 `sqlfluff:LT08` L32
  第32行：CTE 闭括号之后缺少空行。
  建议: 在 `)` 与 `SELECT * FROM cte;` 之间插入一个空行。
- 🔴 `sqlfluff:AM02` L41
  第41行：建议使用 `UNION DISTINCT` 或 `UNION ALL`，不要单独使用 `UNION`。
  建议: 若需要去重，改用 `UNION DISTINCT`；若不需要去重，改用 `UNION ALL`（通常性能更好）。
- 🔴 `sqlfluff:LT11` L41
  第41行：集合运算符前后都应加换行。
  建议: 将 `UNION` 放到单独一行，并让它前面和后面各有一行，例如：
`SELECT id FROM my_table
UNION
SELECT id FROM other_table;`
- 🔴 `sqlfluff:LT12` L42
  文件末尾：文件必须以一个单独的换行符结束。
  建议: 在最后一行之后补一个换行符，并确保末尾没有多余空行。

AI 审查 · 4 条建议

- 🟡 [AI] [design] `long-identifier` L13
  **过长的标识符影响可移植性与可维护性**
  第13行的列名本身接近80个字符，即使不考虑第13行的行长度限制，这个标识符也过长，可能超过部分数据库的标识符上限（如 MySQL 64、PostgreSQL 63、Oracle 128），并显著影响可读性与可维护性。
  建议: 在建表/查询中改用简短、有意义的列名（如 `long_total`），并在应用层建立字段映射；若不能改名，请确认目标数据库的标识符上限并添加注释。
- 🟡 [AI] [performance] `redundant-distinct` L35
  **DISTINCT 可能冗余**
  第35行 `SELECT DISTINCT id FROM my_table;` 如果 `id` 是主键或唯一列，`DISTINCT` 不会改变结果，却会引入额外的排序/哈希操作，增加查询开销。请确认 `id` 的唯一性；若已唯一，应去掉 `DISTINCT`。
  建议: 若 `id` 已唯一，将 `SELECT DISTINCT id` 改为 `SELECT id`。
- 🟡 [AI] [bug] `union-compatible-types` L41
  **UNION 两侧字段类型需保证兼容**
  第41行通过 `UNION` 合并 `my_table.id` 与 `other_table.id`。若两侧类型不同，数据库将进行隐式转换，可能造成转换错误、精度损失或性能下降。建议显式转换为同一类型后再合并。
  建议: 根据实际类型显式转换，例如：
`SELECT CAST(id AS INTEGER) FROM my_table`
`UNION`
`SELECT CAST(id AS INTEGER) FROM other_table;`
- 🔵 [AI] [design] `avoid-select-star` L2
  **避免使用 SELECT ***
  第2、26、32行使用了 `SELECT *`。如果表结构日后新增列，结果集会随之变化，可能意外暴露敏感字段并增加不必要的数据传输。建议在正式查询中显式列出所需字段。
  建议: 将 `SELECT *` 改为显式字段列表，例如只需要 `id` 时写 `SELECT id`。