当前位置: 首页 > 编程笔记 >

MySQL批量插入和唯一索引问题的解决方法

阴焱
2023-03-14
本文向大家介绍MySQL批量插入和唯一索引问题的解决方法,包括了MySQL批量插入和唯一索引问题的解决方法的使用技巧和注意事项,需要的朋友参考一下

MySQL批量插入问题

在开发项目时,因为有一些旧html" target="_blank">系统的基础数据需要提前导入,所以我在导入时做了批量导入操作 ,但是因为MySQL中的一次可接受的SQL语句大小受限制所以我每次批量虽然只有500条,但依然无法插入,这个时候代码报错如下:

nested exception is com.mysql.jdbc.PacketTooBigException: Packet for query is too large (5677854 > 1048576).

You can change this value on the server by setting the max_allowed_packet' variable.

根据报错我们很快就可以知道,是SQL语句数据包太大导致,我们可以设置MySQL服务器参数max_allowed_packet来解决这个问题。

解决办法

1.添加【mysqld】下max_allowed_packet参数,设置的尽量大一些。

#找到my.cnf文件
#whereis my.cnf
#vim my.cnf
----------------------------
[mysqld]
max_connections =3000
max_allowed_packet=1024M

#保存后重启mysql服务,即可生效
#service mysqld restart

2.临时设置max_allowed_packet,通过语句设置

myslq>set global max_allowed_packet = 1024*1024*1024

该种方式重启后就max_allowed_packet失效了

默认情况下Mysql参数max_allowed_packet值是1M.

MySQL索引不区分大小写问题

当在MySQL数据库中,创建索引默认是不区分大小写的,比如说如下语句:

CREATE TABLE `location` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 `rc` varchar(2) DEFAULT NULL COMMENT 'R/C',
 `location_code` varchar(4) DEFAULT NULL COMMENT '地点编码',
 `location_name` varchar(30) DEFAULT NULL COMMENT '地点名称',
 `zip_code` varchar(6) DEFAULT NULL COMMENT '邮编',
 `address` varchar(50) DEFAULT NULL COMMENT '地址',
 `link_man` varchar(15) DEFAULT NULL COMMENT '联系人',
 `link_phone` varchar(30) DEFAULT NULL COMMENT '联系电话',
 `fax` varchar(30) DEFAULT NULL COMMENT '传真',
 `can_accept_car_time` varchar(40) DEFAULT NULL COMMENT '可接车时间',
 `type` varchar(1) DEFAULT NULL COMMENT '分类',
 `maintenance_type` varchar(1) DEFAULT NULL COMMENT '维护类型',
 `brand` varchar(4) DEFAULT NULL COMMENT '品牌',
 `reservation` varchar(40) DEFAULT NULL COMMENT '预留',
 `enable` int(1) DEFAULT '1',
 `msg_code` varchar(64) NOT NULL COMMENT '消息编码',
 `receive_on` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '接收日期',
 `create_on` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建日期',
 `modified_on` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '修改日期',
 PRIMARY KEY (`id`),
 UNIQUE KEY `unique_msg_code` (`msg_code`) USING BTREE,
 UNIQUE KEY `unique_location_code` (`location_code`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=16325 DEFAULT CHARSET=utf8 COMMENT='地址表';

但当我插入地址编码分别为H12C与h12C时,就报错了,抛出异常:Duplicate entry 'H12C' for key 'normal_localtion_code',这里则说明不区分大小写,所以这个地方需要解决这个问题。

解决方法

1.设置字段为Binary,那么索引就可以区分大小写了。

CREATE TABLE `location` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 `rc` char(2) DEFAULT NULL COMMENT 'R/C',
 `location_code` varchar(4) CHARACTER SET utf8 COLLATE utf8_bin DEFAULT NULL COMMENT '地点编码',
 `location_name` varchar(26) DEFAULT NULL COMMENT '地点名称',
 `zip_code` varchar(6) DEFAULT NULL COMMENT '邮编',
 `address` varchar(50) DEFAULT NULL COMMENT '地址',
 `link_man` varchar(16) DEFAULT NULL COMMENT '联系人',
 `link_phone` varchar(30) DEFAULT NULL COMMENT '联系电话',
 `fax` varchar(30) DEFAULT NULL COMMENT '传真',
 `can_accept_car_time` varchar(40) DEFAULT NULL COMMENT '可接车时间',
 `type` varchar(1) DEFAULT NULL COMMENT '分类',
 `maintenance_type` varchar(1) DEFAULT NULL COMMENT '维护类型',
 `brand` varchar(4) DEFAULT NULL COMMENT '品牌',
 `reservation` varchar(40) DEFAULT NULL COMMENT '预留',
 `enable` int(1) DEFAULT '1',
 `msg_code` varchar(64) NOT NULL COMMENT '消息编码',
 `receive_on` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '接收日期',
 `create_on` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建日期',
 `modified_on` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '修改日期',
 PRIMARY KEY (`id`),
 UNIQUE KEY `unique_msg_code` (`msg_code`) USING BTREE,
 UNIQUE KEY `unique_location_code` (`location_code`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=4092 DEFAULT CHARSET=utf8 COMMENT='地点表';

// 修改原表字典属性:

ALTER TABLE `location`
CHANGE COLUMN `location_code` `location_code` VARCHAR(4) CHARACTER SET 'utf8' BINARY NOT NULL DEFAULT '' ;

上面方法就解决了。

查询时不区分大小写问题

解决方法


1.查询语句加binary

2.与索引解决方案一致,设置字段属性为binary即可。

总结

以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,谢谢大家对小牛知识库的支持。

 类似资料:
  • 本文向大家介绍MySQL普通索引和唯一索引的深入讲解,包括了MySQL普通索引和唯一索引的深入讲解的使用技巧和注意事项,需要的朋友参考一下 场景 1、维护一个市民系统,有一个字段为身份证号 2、业务代码能保证不会写入两个重复的身份证号(如果业务无法保证,可以依赖数据库的唯一索引来进行约束) 3、常用SQL查询语句:SELECT name FROM CUser WHERE id_card = 'XX

  • 问题内容: 我正在尝试将数据从此链接插入到我的SQL Server https://www.ian.com/affiliatecenter/include/V2/CityCoordinatesList.zip 我创建了表 我正在运行以下脚本来进行批量插入 但是批量插入失败,并出现以下错误 当我使用google时,我发现了几篇文章,指出问题可能出在RowTerminator上,但我尝试了诸如/ n

  • 本文向大家介绍MySQL死锁套路之唯一索引下批量插入顺序不一致,包括了MySQL死锁套路之唯一索引下批量插入顺序不一致的使用技巧和注意事项,需要的朋友参考一下 前言 死锁的本质是资源竞争,批量插入如果顺序不一致很容易导致死锁,我们来分析一下这个情况。为了方便演示,把批量插入改写为了多条 insert。 先来做几个小实验,简化的表结构如下 实验1: 在记录不存在的情况下,两个同样顺序的批量 inse

  • 本文向大家介绍MySQL插入emoji表情失败问题的解决方法,包括了MySQL插入emoji表情失败问题的解决方法的使用技巧和注意事项,需要的朋友参考一下 前言 之前一直认为UTF-8是万能的字符集问题解决方案,直到最近遇到这个问题。最近在做新浪微博的爬虫, 在存库的时候发现只要保持emoji表情,就回抛出以下异常: 众所周知UTF-8是3个字节, 其中已经包括我们日常能见过的绝大多数字体. 但3

  • 我创建下表: 我的问题是我是否需要这句话: ? 是否自动对创建索引?

  • 问题内容: 就性能而言,MySQL唯一索引和非唯一索引有什么区别? 假设我要在2列的组合上创建索引,并且该组合是唯一的,但是我创建了一个非唯一的索引。这会对MySQL使用的性能或内存产生重大影响吗? 同样的问题, 主 键和 唯一 索引之间有区别吗? 问题答案: UNIQUE和PRIMARY KEY是 约束 ,而不是索引。尽管大多数数据库通过使用索引来实现这些约束。除了索引之外,约束的额外开销也微不