MySQL和PostgreSQL的JSON类型均采用二进制存储（JSONB），但MySQL 8.0为文本存储加部分解析，PostgreSQL JSONB则预解析为优化二进制格式，带来查询加速、存储压缩及GIN索引支持等优势。
存储过程里直接存大文件？别这么干
SQL 存储过程中不能也不该把图片、PDF、视频二进制内容直接塞进 INSERT 或 UPDATE 语句里拼接处理。常见错误是用 CONCAT 拼接 base64 字符串再转 UNHEX，结果触发 max_allowed_packet 限制、超时或隐式截断——MySQL 默认只允许 4MB，而一张高清图就可能超限。
真正可行的做法只有两种：
- 在存储过程里只操作路径或 ID：把文件先存到文件系统或对象存储（如 S3、MinIO），然后在存储过程中仅插入/更新路径字段（
VARCHAR）或元数据 ID（BIGINT） - 若必须存二进制，用
LONGBLOB字段 + 客户端分块上传，存储过程只负责收尾校验和事务提交，不参与读取/解码
JSON 字段在存储过程中怎么安全解析和关联？
MySQL 存储过程支持 JSON_CONTAINS、JSON_EXTRACT 等函数，但直接在 WHERE 或 JOIN 中调用它们做实时解析，性能极差——每次执行都全表解析 JSON 字段，无法走索引。
正确做法是前置结构化：
- 在存储过程开头，用
JSON_TABLE（MySQL 8.0.4+）把目标 JSON 字段展开为临时结果集，再CREATE TEMPORARY TABLE缓存；后续所有关联都基于这张临时表，而非原始 JSON 列 - 对高频查询字段（如
$.user_id、$.status），在建表时就定义生成列并加索引：ALTER TABLE logs ADD COLUMN user_id INT AS (JSON_UNQUOTE(JSON_EXTRACT(content, '$.user_id'))) STORED，再CREATE INDEX idx_user_id ON logs(user_id) - 避免在存储过程循环体里反复调用
JSON_CONTAINS(details, '"error"')——提取逻辑应提前完成，循环只做简单判断
SQL Server 存储过程调用 FileTable 怎么避免权限失败？
SQL Server 存储过程里通过 INSERT INTO [Documents] 写入 FileTable，常报错 The file system directory associated with the FILESTREAM column does not exist 或 Access is denied，根本原因是：FileTable 的文件系统访问依赖 Windows 身份验证上下文，而存储过程默认以 SQL 登录身份运行，无权写入 NTFS 目录。
绕过方式很明确：
- 不要在存储过程中直接
INSERT到 FileTable 的file_stream列；改用OPENROWSET(BULK ...)加载二进制，或更稳妥地——让应用层把文件写入共享目录，存储过程只更新元数据表（如document_metadata） - 若必须由数据库侧触发，启用
NON_TRANSACTED_ACCESS = FULL后，用GET_FILESTREAM_TRANSACTION_CONTEXT()获取上下文，并确保存储过程以EXECUTE AS OWNER方式运行，且 Owner 是有目录写权限的 Windows 登录用户 - 永远检查
FILETABLE_DIRECTORY是否已设为非空字符串，否则SELECT GET_FILESTREAM_TRANSACTION_CONTEXT()返回NULL，后续所有操作静默失败
PostgreSQL 存储过程里处理 JSONB 怎么不拖慢整个事务？
PostgreSQL 的 jsonb 支持很好，但存储过程里频繁用 jsonb_path_query 或 jsonb_array_elements 做嵌套展开，会导致 CPU 占用飙升、锁等待加剧——尤其当目标表行数过万时，单次调用可能耗时数百毫秒。
关键约束点在于：jsonb 函数无法下推到索引扫描中，只能后过滤。
- 高频查询字段（如
data->>'category'）必须建表达式索引：CREATE INDEX idx_category ON items ((data->>'category'))，并在存储过程中显式引用该表达式，而非重新解析 - 避免在
FOR循环内对同一 jsonb 字段重复调用data->'items'；先用SELECT data->'items' INTO v_items FROM ...提前提取，循环里只操作v_items - 大数组展开（如
jsonb_array_elements(data->'events')）务必加LIMIT控制返回行数，否则可能瞬间生成数万行中间结果，撑爆 work_mem
最易被忽略的是：所有数据库的存储过程都默认关闭查询计划缓存（尤其涉及动态 SQL 时），JSON 解析类操作几乎每次重编译。如果业务要求低延迟，这类逻辑本就不该放在存储过程里——交给应用层用专用 JSON 库（如 simdjson、Jackson）更快更稳。
