锐客网

  1. 首页 > 生活百科 > it技术 > >

mysql表太大怎么解决 mysql表数据量太大导致查询不了

IT技术数据

mysql的一个表太大了，400多g,在数据库里面删了两天半都删不掉，请问可1把需要的记录导出.
2 把这个表删除
3, 建立一个跟原来一样的表,
4 把导出的数据导入
数据库表太大影响insert吗影响，1.尽量使语句符合查询优化器的规则避免全表扫描而使用索引查询
【mysql表太大怎么解决 mysql表数据量太大导致查询不了】2.避免频繁创建和删除临时表，以减少系统表资源的消耗 。
3.尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理 。
4.建立高效的索引
SQL语句的Select部分只写必要的列；尽量将In子查询重写为Exists子查询；
去除在谓词列上编写的任何数学运算；尽可能不用Distinct；
由于优化工具处理“或”逻辑可能有问题，所以尽量采用其他方式重写；
确保所处理的表中数据分布和其他统计信息正确，并反映当前状况；尽可能用UNION ALL取代UNION；
尽可能减少DB2的SQL请求；尽量将区间谓词重写为Between谓词；不要只是为了排序而选择某一列；
Mysql大表加索引 select (*) from tb_name where create_timexxx;
最终得知是因为这个表数据行数已经超过 一千万了mysql表太大怎么解决，然后create_time字段又没有索引。
那解决办法肯定是加索引喽 。
但是这个表是一直在线上运行mysql表太大怎么解决 ， 很重要和业务部分 。如果给千万级的大表在线加索引 ，肯定会卡死 。
然后就搜罗了一大筐解决方案，比如 在线无锁加索引使用
ALTER TABLE tbl_name ADD PRIMARY(column), ALGORITHM=INPLACE, LOCK=NONE;
后来才发现，这个特性是 Mysql 5.6 以后才支持，然而我们的mysql用的是5.5版本
最后在 《高性能Mysql》一书中看到，可在通过 “影子拷贝”来解决，
就是 先创建一张和源表无关的新表，然后通过重命名和删表操作交换两张表；
当给新表加完索引后 ， 最上面那条查询直接就是0.0002s
场景：在给一张有几万条记录的表添加索引时，进度非常慢，导致其它查询无法进行
处理方式：
使用Navicat的命令行模式，执行以下命令：
show processlist;
这时会看到有哪些线程正在执行 ， 也可以查看锁表的线程 。你会发现alter table * add key ****那个线程状态是Waiting for table metadata lock，后面有个这个表的所有操作都是这个状态，很明显是这条加索引的语句把表给锁了 。
查看线程ID ， 执行
kill 线程ID
这样被锁住的表就能立即被使用了 。
由此得出一个结论，当一张表数据量很大时，不要轻易添加索引 ， 会导致表被锁死！如果非要添加，那么应该先把数据表进行备份，然后进行空表添加索引 。
只能通过ALTER TABLE不能create index
参数说明：
mysql单库负载过高的处理方式请点击输入图片描述（最多18字）
经常混迹于技术社区，频繁看到这个题目 ， 今天干脆在自己博客重复一遍解决办法：
针对mysql，sqlserver等关系型数据库单表数据过大的处理方式
如果不是阿里云的分布式数据库 DRDS 那种多机器集群方案的话： 先考虑表分区 ；然后考虑分表 ；然后考虑分库 。
这个题目是我所经历过的，我做的是GPS应用，早期版本就是选用的关系型数据库Sql Server 。当时我选取的方案就是第一种：表分区 。表分区的优势是，如果表结构合理 ， 可以不涉及到程序修改 。也就是说，对程序来讲依然是单表读写的效果！
所有轨迹数据存入到一个巨大的表里 。有多大呢？
最大存储量超过10亿行 。具体数值应该是12亿多点，由于系统设计为只存储30天轨迹 ， 所以线上期间最大存储只到这个数，再后来采用云架构 ， 上云替换成非关系性数据库，获得了更高的写入性能和存储压缩能力 。
每日写入量就超过1500万行 。上下班交通高峰时候每秒写入量平均超过500行 。也就是500iops，距离系统设计的压测指标3000还有一大截
这张大型单表设计要点：（一个聚集索引用于写入 ， 一个联合索引用于查询，没有主键，使用表分区）
明确主键用途：
真的需要查询单行数据时候才需要主键！
我采用无主键设计 ， 用于避免写入时候浪费维护插入数据的性能 。最早使用聚集的类似自增的id主键，压测写入超过5亿行的时候 ， 写入性能缩减一半
准确适用聚集：
写入的数据在硬盘物理顺序上是追加 ， 而不是插入！
我把时间戳字段设置为聚集索引 ， 用于聚集写入目的设计 。保证硬盘上的物理写入顺序，不浪费性能用于插入数据
职责足够单一：
用于精准索引！
使用时间 设备联合索引，保证这张表只有一个查询用途 。保证系统只有一种查询目的：按照设备号 ， 查询一个时间段的数据 。
精确的表分区：
要求查询时候限定最大量或者最大取值范围！
按天进行表分区，实现大数据量下的高效查询 。这里是本文重点，按照聚集索引进行，可以让目标数据局限在更小的范围进行，虽然单表数据上亿，但是查询基本上只在某一天的的几千万里进行索引查询
每张表会有各自的特点，不可生搬硬套，总结下我这张表的特点：
只增，不删，不改！
关于不删除中：每天使用作业删除超过30天的那个分区数据除外，因为要清空旧的表分区，腾出新的表分区！
只有一个业务查询：只按照设备编码查询某个时间段
只有一个运维删除：删除旧的分区数据
这张表 ， 是我技术生涯中进步的一个大阶梯，让我我体会到了系统架构的意义 。
虽然我的这张举行表看似只有4个关键点，但是这四个非常精准的关键点设计，耗费了我一个月之久！正是这么足够精准的表结构设计 ， 才撑起了后来压测并发量超过3000的并发写入量！压测的指标跟数据库所在的硬盘有直接关系，当时选取的硬盘是4块10000转的SAS盘做了Raid10的环境
关于后来为什么没有更高的实际应用数值 ， 是因为系统后来改版为云架构，使用了阿里云 ， 更改为写入性能更高的非关系型数
mysql数据库表太大查询慢优化的几种方法优化方案：
主从同步 读写分离：
这个表在有设备条件的情况下，读写分离 ， 这样能减少很多压力，而且数据稳定性也能提高
纵向分表：
根据原则，每个表最多不要超过5个索引，纵向拆分字段，将部分字段拆到一个新表
通常我们按以下原则进行垂直拆分:（先区分这个表中的冷热数据字段）
把不常用的字段单独放在一张表;
把text ， blob等大字段拆分出来放在附表中;
经常组合查询的列放在一张表中;
缺点是：很多逻辑需要重写，带来很大的工作量 。
利用表分区：
这个是推荐的一个解决方案，不会带来重写逻辑等 ， 可以根据时间来进行表分区，相当于在同一个磁盘上，表的数据存在不同的文件夹内，能够极大的提高查询速度 。
横向分表：
1000W条数据不少的，会带来一些运维压力，备份的时候，单表备份所需时间会很长，所以可以根据服务器硬件条件进行水平分表 ， 每个表有多少数据为准 。
Mysql单表太大，性能受影响求指点这么大的表优化是很痛苦的mysql表太大怎么解决，看mysql表太大怎么解决你对数据的用途mysql表太大怎么解决，如果不经常查询、而是频繁的增加 ， 可以考虑定期（每周或者每日）把表中的数据复制到历史表中，清空工作表的数据，这样插入的效率能大大提高，但是查询的时候需要在两个表中进行查询 。用于频繁插入数据的工作表要尽量少建索引，用于查询的历史表要多建索引 。
关于mysql表太大怎么解决和mysql表数据量太大导致查询不了的介绍到此就结束了 ， 不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站 。

    推荐阅读


    上一篇：视频号文玩类目申请，申请官方视频号

    下一篇：塔塔sap怎么样，塔塔技术公司怎么样