查出来全是null主要是因left join右表无匹配数据且未用coalesce处理空值，或源表本身缺失数据；需检查join条件、改用inner join验证，并对可能为空字段显式赋予默认值。
用 CREATE VIEW 拼接测试数据时，为什么查出来全是 NULL？
常见现象是：视图定义里用了 LEFT JOIN 或子查询，但没加 COALESCE 或默认值，导致字段为空；或者源表本身数据不全，JOIN 条件写成 ON a.id = b.id AND b.status = 'active' 却忘了 b 表里根本没匹配的记录。
- 先确认所有 JOIN 的右表是否有对应数据，临时改用
INNER JOIN测试是否能出结果 - 对可能为空的字段，显式用
COALESCE(<code>col, 'N/A') 或COALESCE(<code>col, 0) - 避免在视图里依赖外部变量（比如用户传参），SQL 视图不支持参数化，真要动态得用函数或 CTE 替代
MySQL 和 PostgreSQL 的 CREATE VIEW 在测试数据生成上关键差异
PostgreSQL 支持 MATERIALIZED VIEW，可缓存结果、支持索引，适合反复查的模拟数据集；MySQL 8.0+ 虽然也支持视图，但每次查询都会重跑底层 SQL，如果里面套了多层子查询或 RAND()，性能会明显下降。
- MySQL 中慎用
RAND()+LIMIT组合做随机采样——视图里不能保证每次执行都“真随机”，有时会固化结果 - PostgreSQL 若需更新物化视图，必须手动执行
REFRESH MATERIALIZED VIEW，别指望它自动同步源表变更 - 两者都不支持在视图定义中直接写
INSERT或UPDATE，想生成带主键递增的数据，得靠序列（GENERATED ALWAYS AS IDENTITY）或ROW_NUMBER() OVER ()
用 UNION ALL 模拟多状态业务数据时，字段顺序和类型必须严格一致
比如想造出「已下单」「已发货」「已签收」三种订单状态的混合测试集，用三个 SELECT 做 UNION ALL，但第二条 SELECT 里把 created_at 写成字符串 '2024-01-01'，而第一条是真正的 DATETIME 类型，MySQL 会隐式转成字符串，导致后续排序或范围查询失效。
- 所有
UNION ALL分支的列数、顺序、类型必须完全一致；不确定时，统一显式转换：CAST('2024-01-01' AS DATETIME) - 别为了省事在每条 SELECT 里都写
*，字段顺序稍有变动就会错位；明确列出字段名，并按需补占位值：NULL AS shipped_at - 如果某状态不需要某个字段（如「已下单」还没有物流单号），就用
NULL占位，别漏掉
视图里调用 UUID() 或 gen_random_uuid() 为什么每次查都一样？
这是最常被忽略的点：MySQL 的 UUID() 在视图中不是“每行调用一次”，而是整个语句执行时只调一次，结果被广播到所有行；PostgreSQL 的 gen_random_uuid() 同理，除非你把它包进子查询或 CTE 里强制按行求值。
- MySQL 正确做法：用
CONCAT(UNHEX(SHA1(RAND())), '-', UNHEX(SHA1(RAND())))这类组合绕过缓存（不完美但够用） - PostgreSQL 推荐写法：
SELECT *, gen_random_uuid() FROM (SELECT * FROM generate_series(1,100)) t，把随机函数放在内层 SELECT - 更稳妥的方案是放弃视图，改用临时表 +
INSERT ... SELECT插入带真实随机值的数据，尤其当测试需要唯一性保障时
真正难的不是写视图，是让视图里的“假数据”在多次查询、跨会话、不同客户端下行为稳定且符合预期。随机性、NULL 处理、类型隐式转换，这三个地方一松懈，测出来的问题就不是数据不对，而是根本复现不了。
