DISTINCT仅用于SELECT语句中对查询结果去重，不能用于INSERT、UPDATE或DELETE；它必须位于SELECT后第一位，作用于指定列的整行组合，不支持插入时动态防重。
DISTINCT 不能直接用于 INSERT 语句中过滤源数据重复项——它不是 INSERT 的修饰符，也不能“自动去重插入”。想靠 INSERT ... SELECT DISTINCT 实现去重插入，必须明确作用对象：是去重 SELECT 的结果集，而非“在插入过程中动态拦截重复行”。
为什么 DISTINCT 不能用于 INSERT VALUES 场景？
INSERT INTO table VALUES (...) 是显式提供值的语法，DISTINCT 对它完全无效，SQL 解析器会直接报错：ERROR: syntax error at or near "DISTINCT"。DISTINCT 只能修饰 SELECT 子句，作用于查询结果集的行级去重。
-
INSERT INTO t (a,b) VALUES (1,2), (1,2);—— 这种写法无论加不加 DISTINCT 都会插入两行（除非有唯一约束拦截） - 想对多行字面量去重？必须先转成子查询：
INSERT INTO t (a,b) SELECT DISTINCT a,b FROM (VALUES (1,2), (1,2)) AS v(a,b); - 注意：PostgreSQL 支持
VALUES作为表表达式，但 MySQL 不支持这种写法，需改用UNION或临时表
INSERT ... SELECT DISTINCT 的真实行为和陷阱
这是最常用也最容易误解的写法：INSERT INTO target SELECT DISTINCT col1, col2 FROM source;。它的去重范围仅限于 SELECT 输出的列组合，且只发生在查询阶段——不关心目标表是否已有相同数据。
- 如果
source表本身有 10 行，其中 3 行(col1,col2)完全相同，则SELECT DISTINCT只返回 1 行，INSERT 就只插 1 行 - 但如果目标表
target已存在该(col1,col2)组合，这条 INSERT 仍会成功（除非定义了唯一索引或主键约束） - 去重依据是 SELECT 列的完整组合：
SELECT DISTINCT a,b和SELECT DISTINCT a,b,c结果完全不同，哪怕c是 NULL 或常量 - 性能影响：DISTINCT 通常触发排序或哈希去重，大数据量时可能显著拖慢 SELECT 阶段
真正防止重复插入的替代方案
要确保目标表不出现重复，靠 DISTINCT 远不够。实际生产中必须结合约束与原子化操作：
- 在目标表上建唯一索引：
CREATE UNIQUE INDEX idx_uq ON target(col1, col2);—— 这是基础防线 - 用
INSERT ... ON CONFLICT DO NOTHING（PostgreSQL）或INSERT IGNORE（MySQL）跳过冲突行 - 用
MERGE（SQL Server / Oracle）或INSERT ... SELECT ... WHERE NOT EXISTS做存在性检查 - 避免在应用层做“先查再插”：并发下必然产生竞态，查到不存在，另一事务插入后，本事务再插就重复了
关键点在于：DISTINCT 是查询阶段的投影去重工具，不是数据写入的防重机制。真正可靠的去重必须依赖唯一约束 + 冲突处理语法，否则只是把问题从插入时推迟到了后续业务逻辑里暴露。
