分类： SQL
-
在 Yii 2.0 中使用数据库迁移创建主键时，默认的 primaryKey() 方法仅支持生成 int(11) 类型的主键，无法直接满足创建 varchar(32) 字符串类型主键的需求。为了解决这个问题，文章采取了先创建字符串类型字段，随后在表创建完成后使用 addPrimaryKey() 方法将该字段设置为主键的操作流程。最终通过这一分步方式成功实现了基于字符串类型的主键功能。
-
在渠道发布中出现 SQLSTATE[01000] 警告，提示 pub_log_code 字段数据截断。排查发现数据库表字段定义为 int 类型，但通过 $e->getCode() 获取的值为字符串 42S22。经确认 Yii 2.0 框架响应的 code 值可能为非数字类型字符串。解决方案包括修改字段类型为 varchar 或转换代码数值类型，同时发现根本原因在于表结构变更导致的 SQL 语法错误异常。
-
本文记录了在 Yii 2.0 中使用 like 操作符查找反斜杠时结果为空的问题。经排查，在 MySQL 5.7.19 版本下，当字段排序规则为 utf8mb4_unicode_ci 时，需在 SQL 中多增加一根反斜杠才能查出数据。对比测试 utf8mb4_general_ci 排序规则则无此现象。查阅官方文档得知这是特定版本下 utf8mb4_unicode_ci 的已知 Bug，该问题在 MySQL 8.0.18 中已修复。
-
本文记录了 MySQL 报错 1055 的解决过程，该错误由于 sql_mode 包含 only_full_group_by 导致非聚合列未出现在 GROUP BY 子句中。文章首先尝试调整 SQL 语句，使查询字段与分组字段完全一致从而消除报错。随后考虑到修改代码成本较高，参考相关技术文档，通过修改配置文件 my.ini 调整设置，最终解决了该兼容性问题。
-
接口响应报错提示 SQL 语法错误，经排查发现当请求参数 filter 包含特定单引号时，生成的 FIND_IN_SET 语句因缺少转义导致异常。对比发现，同条件下 LIKE 语句未报错是因为进行了转义。为解决此问题，参考相关文档在 Yii 2.0 中新增了支持 FIND_IN_SET 函数的条件构建器，并在 ActiveDataFilter 中使用 addslashes 函数对参数值进行转义，修改后接口响应成功，SQL 语句正常执行。
-
在 Rancher 升级容器时遇到数据库迁移重复执行导致报错的问题。经分析，原因是数据库迁移耗时过长致使容器初始化超时，引发健康检查失败和容器反复重启。虽然调整了就绪检测时间，但初始化部署仍报超时。检查 MySQL 发现，特定迁移记录虽不存在于迁移表，但表结构已是执行后的结果，表明迁移曾在后台完成。最终确认需进一步优化检测配置以解决初始化阶段的冲突。
-
本文介绍了在 Yii 2.0 中通过命令行脚本将数据从 csp 数据库迁移至 cloud 数据库的实现过程。通过编写自定义控制器并执行相关命令，从源表筛选出 95 条记录并插入目标表。操作完成后，目标表记录总数变为 253 条，实际新增 95 条数据，符合迁移预期。
-
针对MySQL表注释、字段注释及表中值出现乱码的问题，通过在SQL文件最开头添加SET NAMES utf8mb4;命令，可以有效解决字符编码不匹配的情况，执行后表结构注释与数据内容均能正确显示，不再出现乱码现象。
-
本文探讨了在 Yii 2.0 框架中使用查询构建器定义 LIKE 操作符 WHERE 条件的具体实现。通过设置操作数，包括字段名称、模糊查询值以及可选的转义映射参数，能够灵活控制 SQL 语句的生成逻辑。文章详细说明了如何通过禁用转义功能或使用数组，生成以特定字符前缀开始的查询语句，最终生成的 SQL 语句符合预期。