有业务需求是 如果存在就更新，如果不存在就新增
1、该语句是基于唯一索引或主键使用，需要建立unique index 索引
2、更新操作必须是在已有的数据基础上才会被执行，如果要更新的字段是主键或者唯一索引，不能和表中已有的数据重复，否则插入更新都失败。
3、不管是更新还是增加等操作，都不允许将主键或者唯一索引的字段的数据变成表中已经存在的数据（唯一索引有且只有一个）
使用之后发现ID出现很大的变化，比如一条数据主键id为1，然后第二条就直接是5，这样下去int数据类型估计都撑不住，所以为了解决这样的办法，需要修改innodb_autoinc_lock_mode配置
这个参数控制着在向有auto_increment 列的表插入数据时，相关锁的行为
有0，1，2 这3个级别
分别对应着tradition 、consecutive 、 interleaved
tradition 模式：
1、在这一模式下，所有的insert语句(“insert like”) 都要在语句开始的时候得到一个表级的auto_inc锁，在语句结束的时候才释放这把锁，注意呀，这里说的是语句级而不是事务级的，一个事务可能包涵有一个或多个语句。
2、由于在这种模式下auto_inc锁一直要保持到语句的结束，所以这个就影响到了并发的插入。
consecutive 模式（默认模式）：
1、这一模式下去simple insert 做了优化，由于simple insert一次性插入值的个数可以立马得到确定，所以mysql可以一次生成几个连续的值，用于这个insert语句；总的来说这个对复制也是安全的
(它保证了基于语句复制的安全)
2、这一模式也是mysql的默认模式，这个模式的好处是auto_inc锁不要一直保持到语句的结束，只要
语句得到了相应的值后就可以提前释放锁
interleaved 模式：
1、由于这个模式下已经没有了auto_inc锁，所以这个模式下的性能是最好的；但是它也有一个问题，就是对于同一个语句来说它所得到的auto_increment值可能不是连续的。
三种模式简要说明:
0：traditonal （每次都会产生表锁）
1：consecutive （会产生一个轻量锁，simple insert会获得批量的锁，保证连续插入）
2：interleaved （不会锁表，来一个处理一个，并发最高）
由于之前设置的是1，会有一个轻量锁，当执行insert或update，simple insert一次性插入或更新值的个数可以立马得到，当发现insert失败时，对应的id会被抛弃，沿用下一个id用来insert，这时，mysql已经将id记录了，所以就会出现这样的情况，当设置为0时，每次操作得到一个表级的auto_inc锁，有且只能拿到一个id进行操作，当前insert失败时，由于之前的id没有插入成功，所以此id会被回收，mysql继续发放id用来处理剩下的操作
修改自增锁级别方法:
编辑/etc/my.cnf，加入如下行:
innodb_autoinc_lock_mode=0
参考：https://www.jianshu.com/p/10a8d8977aaf
有业务需求是 如果存在就更新，如果不存在就新增之前用的 django orm中自带的 update_or_create 发现操作1900条数据的时候将近两分钟，太耗时了，然后翻了翻mysql的书籍，发现了ON DUPLICATE KEY UPDATE 方法1、该语句是基于唯一索引或主键使用，需要建立unique index 索引2、更新操作必须是在已有的数据基础上才会被执行，如果要更新的字段是主键或者唯一索引，不能和表中已有的数据重复，否则插入更新都失败。3、不管是更新还是增加等操作，都不
作为程序员的二狗子今天已经把手下的任务做完了，正在假装认真工作的样子尽情摸鱼，二狗子闲得无聊，坐立不安，坐着不是，站着也不是，浑身难受。
老板：“那个.....二狗子，你过来一趟”
二狗子心想，老司机摸鱼被发现啦？怀着忐忑不安的心情去了老板那里。
老板：“这张表主键
ID
设置的自动增长为什么会跳跃增长，而且增长的速度非常快，再这样下去迟早有一天会突破Int的最高数值，你赶紧想办法解决一下！”.........
当我们使用
MySQL
进行数据存储时，一般会为一张表设置一个
自增
主键，当有数据行插入时，该主键字段则会根据步长与偏移量增长（默认每次+1）。
下文以 Innodb 引擎为主进行介绍，使用
自增
主键的好处有很多，如：索引空间占比小、范围查询与排序都友好、避免像 UU
ID
这样随机字符串带来的页分裂问题等…
一、
自增
ID
是.
工作中负责开发的一个准实时的异步写入系统,需要每天将用户的听歌记录写入 数据库 中,
写入量比较大,每天一个表的写入量大概有5000万次左右,有
update
,也有insert.
数据库用的是percona的
MySQL
,上线后一直运行挺好,基本上都是实时的,但是突然有一天发现一个统计用户听歌次数的表数据不更新了,
update
和insert 都不起作用了,非常的诡异,后来运维show crea...
使用唯一索引，不存在则插入，存在则更新
INSERT INTO tb_addrbook(num,name,mobile) VALUE('1001','小李','13112345678') ON
DUPLI
CAT
E
KEY
UPDATE
name= '小李',mobile='13112345678'
但是，大家可能会发现，这个表如果是有设置
自增
ID
的话，这个
自增
ID
并不会按正常的记录增加而加1增长，而是会跳跃增长，增长跨度和SQL的执行次数成正比。当然，
自增
ID
在许多业务中只是作为一个记录唯一性标识而已，跳
CREATE TABLE `test_
dupli
cat
e_
key
` (
`
id
` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键
id
',
`name` varchar(255) DEFAULT NULL,
`age` int(11) ,
PRIMARY
KEY
(`
id
`),
UNIQUE
KEY
`name_
id
x` (`name`)
) ENGINE=InnoDB;
select * from test_
dupli
cat
e_
key
CREATE TABLE sequence(tablename VARCHAR(64) NOT NULL,
id
BIGINT UNSIGNED NOT NULL DEFAULT 1,PRIMARY
KEY
(tablename)) ENGINE=INNODB;
CREATE PROCEDURE pro_sequence(tname VARCHAR(64))
BEGIN
INSERT IN...
最近项目上需要实现这么一个功能:从服务器数据库获取一个json字符串，通过解析获得一个10万量的数据，存入本本地数据库，最开始采用先更新后新增的逻辑进行操作，通过测试逐条更新执行完，整个代码是在10分钟左右，效率低下，所以采用了如下代码
<insert
id
="insertPackWmsOperator" parameterType="java.util.List" useGenerated
Key
s="true"
key
Property="
id
">
insert into pack_
小A正在balabala写代码呢，DBA小B突然发来了一条消息，“快看看你的用户特定信息表T，里面的主键，也就是
自增
id
，都到16亿了，这才多久，在这样下去过不了多久主键就要超出范围了，插入就会失败，balabala......”
我记得没有这么多，最多1k多万，count了下，果然是1100万。原来运维是通过auto_increment那个值看的，就是说，表中有大量的删除插入操作，但是我大部分情况都是更新的，怎么会这样？
这张表是一个简单的接口服务在使用，每天大数据会统计一大批信息
nginx报错upstream prematurely closed connection while reading response header from upstream
所以新手使用celery很仔细的建立文件夹名字、文件夹层级、python文件名字，
所以网上的celery博客教程虽然很多，但是并不能学会使用，因为要运行起来需要以下6个方面都掌握好，博客文字很难表达清楚或者没有写全面以下6个方面。
celery消费任务不执行或者报错NotRegistered，与很多方面有关系，如果要别人排错，至少要发以下6方面的截图，
1) 整个项目目录结构,celery的目录结构和任务函数位置，有很大影响
2) @task入参 ,用户有没有主动设置装饰器的入参 name,设置了和没设置有很大不同，建议主动设置这个名字对函数名字和所处位置依赖减小
3) celery的配置，task_queues(在3.xx叫 CELERY_QUEUES )和task_routes (在3.xx叫 task_routes)
4) celery的配置 include （在3.xx叫 CELERY_INCLUDE）或者 imports (3.xx CELERY_IMPORTS) 或者 app.autodiscover_tasks的入参
5) cmd命令行启动参数 --queues= 的值
6) 用户在启动cmd命令行时候，用户所在的文件夹。
在不规范的文件夹路径下，使用celery难度很高，一般教程都没教。
[项目文件夹目录格式不规范下的celery使用演示](https://github.com/ydf0509/celery_demo)
此国产分布式函数调度框架 https://function-scheduling-distributed-framework.readthedocs.io/zh_CN/latest/index.html ，
从用法调用难度，用户所需代码量，超高并发性能，qps控频精确程度，支持的中间件类型，任务控制方式，稳定程度等19个方面全方位超过celery，任何方面都是有过之而无不及 。
celery详解（使用django+celery实现异步及定时任务以及使用supervisor进行管理）
程序员托马斯:
