MariaDB 10.3 instant ADD COLUMN亿级大表毫秒级加字段

加字段是痛苦的，需要对表进行重建，尤其是对亿级别的大表，虽然Online DDL可以避免锁表，但如果在主库上执行耗时30分钟，那么再复制到从库上执行，主从复制就出现延迟。使用instant ADD COLUMN特性，只需弹下烟灰的时间，字段就加好了，享受MongoDB那样的非结构化存储的灵活方便。

限制
1、如果指定了AFTER，字段必须是在最后一列，否则会重新建立表
2、不适用于ROW_FORMAT = COMPRESSED
3、DROP COLUMN需要重建表

原文地址：http://blog.51cto.com/hcymysql/2139959

时间： 2024-10-08 16:09:39

MariaDB 10.3 instant ADD COLUMN亿级大表毫秒级加字段的相关文章

Mysql千万级大表优化

Mysql的单张表的最大数据存储量尚没有定论,一般情况下mysql单表记录超过千万以后性能会变得很差.因此,总结一些相关的Mysql千万级大表的优化策略. 1.优化sql以及索引 1.1优化sql 1.有索引但未被用到的情况(不建议) (1)避免like的参数以通配符开头时尽量避免Like的参数以通配符开头,否则数据库引擎会放弃使用索引而进行全表扫描. 以通配符开头的sql语句,例如:select * from t_credit_detail where Flistid like '%0'\G

Python获取秒级时间戳与毫秒级时间戳

原始链接:https://www.cnblogs.com/fangbei/p/python-time.html 1.获取秒级时间戳与毫秒级时间戳.微秒级时间戳 import time import datetime t = time.time() print (t) #原始时间数据 print (int(t)) #秒级时间戳 print (int(round(t * 1000))) #毫秒级时间戳 print (int(round(t * 1000000))) #微秒级时间戳返回 149982

获取秒级时间戳和毫秒级时间戳---基于python

获取秒级时间戳和毫秒级时间戳 import timeimport datetime t = time.time() print (t) #原始时间数据print (int(t)) #秒级时间戳print (int(round(t * 1000))) #毫秒级时间戳 nowTime = lambda:int(round(t * 1000))print (nowTime()); #毫秒级时间戳,基于lambda print (datetime.datetime.now().strftime('%Y-

[生产库实战] 如何使用触发器对生产库上亿级大表进行实时同步

触发器迁移数据和MV的原理相同,通过在源表创建Trigger,记录源表的DML操作日志,然后通过存储过程同步DML受影响的记录,达到目标表和源表数据一致的效果.此方法只是对Prebuilt MV操作的一个补充.物化视图/在线重定义对DML频繁的大表进行处理时,存在一个弊端,主要是在全量初始化这个步骤上,比如: 本应该多块扫描,直接路径读效率很高的,但由于个别数据块在内存造成单块读; 或由于DML操作相对频繁,可能读到的数据需要与undo构造一致性读数据块的几率也较高,此时查看等待事件都是采用单块

财务平台亿级数据量毫秒级查询优化之elasticsearch原理解析（转）

https://blog.csdn.net/wang123459/article/details/81045416 财务平台进行分录分表以后,随着数据量的日渐递增,业务人员对账务数据的实时分析响应时间越来越长,体验性慢慢下降,之前我们基于mysql的性能优化做了一遍,可以说基于mysql该做的优化已经基本上都做了,本次是基于elasticsearch对其做进一步的性能优化正文 1mysql索引原理基于mysql最常用也最直接有效的性能优化也就是添加索引. mysql索引是怎么实现的呢?数据库

【优化】MySQL千万级大表优化解决方案

问题概述使用阿里云rds for MySQL数据库(就是MySQL5.6版本),有个用户上网记录表6个月的数据量近2000万,保留最近一年的数据量达到4000万,查询速度极慢,日常卡死.严重影响业务. 问题前提:老系统,当时设计系统的人大概是大学没毕业,表设计和sql语句写的不仅仅是垃圾,简直无法直视.原开发人员都已离职,到我来维护,这就是传说中的维护不了就跑路,然后我就是掉坑的那个!!! 我尝试解决该问题,so,有个这个日志. 方案概述方案一:优化现有mysql数据库.优点:不影响现有业务

Mysql千万级大表同步复制的一些问题

1 [[email protected] ~]# pt-online-schema-change -u root -p xxxxxx -h localhost -A utf8 D=jinyuanbao,t=DistributionGoods --new-table-name DistributionGoods_0 --no-drop-trigger --no-swap-table --no-drop-new-table --execute 2 No slaves found. See --rec

Oracle优化：千万级大表逻辑判断的累赘

insert into pntmall_point_detail(PNTMALL_PNT_ID, ........... HPT_LEFT_POINT,HPT_FULLREDEMPT_STATUS) SELECT PNTMALL_PNT_ID,.......,PNTMALL_NUM,0 FROM pntmall_point_detail_tmp a WHERE NOT EXISTS (SELECT b.PNTMALL_PNT_ID

mariadb 10.1查看per connection内存消耗

在mariadb 10.1版本中,在information_schema.processlist表中,新增了几个字段,其中有一个memory_used,其记录的是连接的内存消耗. 同时新增了一个状态变量memory_used,其记录的应该是所有连接加起来消耗的内存(官方并没有特别详细地解释https://mariadb.com/kb/en/mariadb/show-processlist/),应该类似于oracle pga的概念. 为了再检查下mysql占用内存远超过buffer pool的原因