分类： SQL
-
针对删除 MySQL 表时因外键约束导致的 1217 报错问题，文章介绍了通过查询 INFORMATION_SCHEMA.KEY_COLUMN_USAGE 表来定位引用关系的方法。根据查询结果筛选出对应的数据库及表名，优先删除引用表后再处理原表，即可解决无法删除的问题并成功完成操作。
-
针对 GraphQL API 请求间歇性返回 500 错误且无响应数据的问题，通过在 index.php 设置错误级别并查看日志，发现 Allowed memory size exhausted 错误。调整内存限制可暂时解决，但进一步排查发现执行 SQL 查询时未添加 limit 约束，导致全表数据加载至内存从而超出限制，添加约束后问题得到定位。
-
面对一张包含17万条记录的表，添加字段操作耗时180秒。通过允许新字段为NULL，耗时降至104秒。进一步确认并清理表中不再使用的数据，将记录量减少至3万余条后再次执行，最终总耗时缩短至87秒。该过程表明，调整字段属性与清理冗余数据能有效缩短表结构变更的执行时间。
-
本文记录了在 Laravel 6 中如何在高级 Join 语句里使用 Where 语句的参数分组，以生成包含多重嵌套条件的 SQL。文章从判断单条记录是否符合复杂嵌套条件的现有实现出发，参照官方文档修改代码，实现了查询所有符合条件的记录，最终生成的 SQL 符合预期。
-
在 Navicat for MySQL 中将表从 5.7 版本数据库复制至 8.0 版本时，因包含默认时间为 0000-00-00 00:00:00 的数据而报错 1292。尝试在 Homestead 配置中禁用 MySQL 8 无果后，对比两个版本的 sql_mode 发现 8.0 默认启用了 NO_ZERO_IN_DATE 和 NO_ZERO_DATE。通过修改目标数据库的 sql_mode，移除上述两项配置并重新连接，再次执行复制操作成功解决了该问题。
-
在 Laravel 6 中，模型应用了软删除后再次插入记录会出现唯一键冲突，这是因为软删除仅更新 deleted_at 字段而未从数据库物理移除记录。由于查询结果自动排除软删除数据，需要使用 withTrashed 方法获取包含软删除在内的记录，再利用 forceDelete 方法进行硬删除。永久删除记录后，再次插入新数据即可避免冲突并成功执行。
-
本文针对 MySQL 5.7 表中 JSON 列类型数据写入后键顺序被打乱的问题进行排查。通过对比原始 JSON 数据顺序与写入数据库后的存储结果，发现数据库中的键顺序变更为基于字母顺序排列，且内部子 JSON 结构的键顺序也发生了变化。经排查验证，将表列类型修改为 text 后，JSON 数据的顺序能够与原始格式保持一致，从而确认了问题源于 MySQL 5.7 JSON 列类型的内部处理机制。
-
针对在本地 Windows 10 环境执行 SQL 查询正常，而在 Linux 容器中无法查询到记录的问题，通过对比发现生成的 SQL 语句差异在于路径分隔符。分析打印生成的 SQL 与 DIRECTORY_SEPARATOR 常量，确认 Windows 环境生成反斜杠而 Linux 环境生成正斜杠，导致拼接后的路径格式不一致。删除代码中依赖 DIRECTORY_SEPARATOR 的拼接部分后，生成的 SQL 在两个操作系统中保持一致，成功解决了查询结果为 NULL 的问题。