mysql insert 空字符报错

本文介绍了解决MySQL在特定版本及配置下插入空字符串到double类型字段时出现的错误问题。通过调整my.ini文件中的sql-mode设置,可以有效避免这一问题。

mysql insert 空字符报错 double类型字段插入空字符串时自动转为0


这样写就会报错:
Data truncated for column 'x1' at row 1
这种应该是版本问题,尤其是虚拟主机。
把''改成null不会出错:
x1是double类型的数据。

INSERT INTO TEMPTABLE(x1,x2,x3,x4,x5,x6,x7,x8,x9,x10,x11,x12,x13,x14,x15,x16,x17,x18,x19,x20,x21,x22,x23,x24,x25,x26,x27,x28,x29,x30,x31,x32,x33,x34,x35,x36,x37,x38,x39,x40,x41,x42,x43,x44,x45,x46,x47,x48,x49,x50,x51,x52,x53,x54,x55,x56,x57,x58,x59,x60,x61,x62,x63,x64,x65,x66,x67,x68,x69,x70,x71,x72,x73,x74,x75,x76,x77,x78,x79,x80,x81,x82,x83,x84,x85,x86,x87,x88,x89,x90,x91,x92,x93,x94,x95,x96,x97,x98,x99,x100,x101,x102,x103,x104,x105,x106,x107,x108,x109,x110,x111,x112,x113,x114,x115,x116,x117,x118,x119,x120,x121,x122,x123,x124,x125,x126,x127,x128,x129,x130,x131,x132,x133) VALUES('0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0','0')

这种问题一般mysql 5.x上出现。我用的mysql5.2.28,后面查询得知新版本mysql对空值插入有"bug",要在安装mysql的时候去除默认勾选的enable strict SQL mode。如果已经安装好了的,就在my.ini中查找sql-mode,默认为sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION",将其修改为sql-mode="NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION",重启mysql后即可。

第一时间的反应是跟mysql5.0新加的sql-mode有关系,因为前一阵子刚刚看过手册.果然,作了如下更改后就不再提示了.

修改 my.ini 文件.

# Set the SQL mode to strict
sql-mode=”STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION”

改为:

# Set the SQL mode to strict
sql-mode=”NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION”

<think>嗯,用户需要解决MySQL存储过程中字符集相关的报错问题。从用户提供的引用内容来看,这个问题主要涉及存储过程中文字符集不匹配导致的数据插入错误或索引失效。 用户可能正在编写包含中文数据的存储过程,遇到了类似"Error 1366"或"无法插入中文"的报错。这类问题通常有四个核心原因需要排查:存储过程本身的字符集声明、连接会话的字符集设置、数据库/表的字符集一致性,以及字符串字面量的隐式转换规则。 参考引用[2]提到的"MySQL存储过程字符集不同索引不生效"和"charset-literal charset-collation-coercibility",需要特别注意字符串字面量的字符集继承规则。根据MySQL官方文档,未显式声明的字符串字面量会继承连接字符集,如果与表字段字符集不一致可能导致索引失效或比较错误。 解决方案应该分层次处理: 首先检查存储过程创建时的字符集设置,可以通过SHOW CREATE PROCEDURE确认。如果未指定,默认会使用数据库字符集,但用户可能需要在CREATE PROCEDURE时显式声明CHARACTER SET utf8mb4。 其次要确保连接会话的字符集一致性,引用[1]提供的SHOW VARIABLES命令可以验证character_set_connection等关键变量。建议在存储过程开头用SET NAMES 'utf8mb4'统一会话设置。 对于表字段字符集,需要确认与连接设置匹配,特别是主表和临时表。引用[3]提到default-character-set=utf8mb4的服务端配置很重要。 最容易被忽视的是字符串字面量的处理。根据用户引用[2]提到的"Character Set Repertoire"规则,在WHERE条件或变量赋值时,应该用CONVERT()函数显式转换字符串,或者使用_N'中文'的写法强制指定字符集。 用户引用[4]的案例很有参考价值,说明存储过程插入中文失败往往源于字符集链断裂。建议用户在存储过程中增加字符集检查语句,类似DECLARE cur_charset VARCHAR(50) DEFAULT @@session.character_set_connection;这样的调试代码。 最后生成的三个相关问题都紧扣用户的使用场景:性能影响对应索引失效问题,迁移方案涉及多环境适配,调试技巧则是实际排错需要的。特别是第二个关于存储过程迁移的问题,考虑到用户可能需要在开发/生产环境同步配置,这点很实用。</think>针对MySQL存储过程中字符集相关的报错问题,以下是系统化的解决方案: --- ### **一、核心原因分析** 1. **字符集链断裂** MySQL处理数据需经过`连接层 → 数据库层 → 表层 → 字段层`的字符集转换,任一环节不匹配会导致乱码或报错。 2. **存储过程特殊机制** - 存储过程内字符串字面量**默认继承`character_set_connection`编码** - 若与表字段字符集不一致,可能引发`Error 1366`(非法字符)或索引失效 --- ### **二、解决方案步骤** #### **步骤1:统一字符集环境** ```sql -- 检查全局字符集(需管理员权限) SHOW GLOBAL VARIABLES WHERE Variable_name LIKE 'character_set_%' OR Variable_name LIKE 'collation%'; -- 修改存储过程使用的字符集(在创建时指定) DELIMITER $$ CREATE PROCEDURE your_procedure() BEGIN -- 显式设置会话字符集 SET NAMES 'utf8mb4' COLLATE 'utf8mb4_unicode_ci'; -- 业务逻辑代码 END $$ DELIMITER ; ``` #### **步骤2:修正字符串字面量** ```sql -- 方法1:强制转换字面量编码 SET @name = CONVERT('中文数据' USING utf8mb4); INSERT INTO your_table (text_column) VALUES (@name); -- 方法2:使用_N前缀(MySQL 8.0+) INSERT INTO your_table (text_column) VALUES (_utf8mb4 '中文数据'); ``` #### **步骤3:验证存储过程字符集** ```sql -- 查看已存在存储过程的字符集 SHOW CREATE PROCEDURE your_procedure_name; -- 重建存储过程(指定字符集) DROP PROCEDURE IF EXISTS your_procedure; CREATE PROCEDURE your_procedure() CHARACTER SET 'utf8mb4' -- 关键声明 BEGIN ... END ``` #### **步骤4:检查表字段一致性** ```sql -- 确认表字段字符集 SHOW FULL COLUMNS FROM your_table; -- 修改字段字符集(示例) ALTER TABLE your_table MODIFY text_column VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ``` --- ### **三、关键配置项** | 配置项 | 推荐值 | 检查命令 | |---------------------------|---------------------|------------------------------------------| | `character_set_client` | utf8mb4 | `SHOW VARIABLES LIKE 'character_set_%';` | | `character_set_connection` | utf8mb4 | | | `character_set_database` | utf8mb4 | | | `collation_connection` | utf8mb4_unicode_ci | | > **注意**:若使用临时表,需显式指定字符集: > ```sql > CREATE TEMPORARY TABLE temp_table (...) > CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; > ``` --- ### **四、调试技巧** 1. **日志追踪** 在存储过程首部添加: ```sql DECLARE cur_charset VARCHAR(50); SET cur_charset = @@session.character_set_connection; SELECT CONCAT('当前字符集:', cur_charset) AS Debug; ``` 2. **逐段隔离** 注释代码块逐步定位报错位置 --- ### **五、典型错误案例** **错误:** `Incorrect string value: '\xE4\xB8\xAD' for column` **原因:** 客户端发送UTF-8数据,但`character_set_connection=latin1` **解决:** 在存储过程入口添加 `SET NAMES utf8mb4;` ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值