首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

MySQL统计数据库所有表的数据量

场景:mysql统计一个数据库里所有表的数据量,最近在做统计想查找一个数据库里基本所有的表数据量数据量少的通过select count再加起来也是可以的,不过表的数据有点多,不可能一个一个地查 记得在...Navicat里,选择一个数据量,点击表,如图: 是可以看到所有表具体的数据行的 然后可以通过sql实现?...在mysql里是可以查询information_schema.tables这张表的 SELECT table_rows,table_name FROM information_schema.tables...大概意思是对于MyISAM才是正确的统计数据,但是对于InnoDB引擎的,可能与实际值相差 40% 到 50%,所以只是一个大概的统计 所以针对这种情况,要更改存储引擎,肯定是不太合适,因为InnoDB...是默认的存储引擎,能支持事务外健,并发情况性能也比较好 所以,根据网上的做法,重新analyze 对应表,在mysql8.0版本是不管用的,发现查询数据还是不对,估计是mysql版本太高,mysql5版本没验证过

6.8K10
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    MySQL每秒57万的写入,带你飞~

    本文作者:吴炳锡 来源:https://yq.aliyun.com/articles/278034 一、需求 一个朋友接到一个需求,从大数据平台收到一个数据写入在20亿+,需要快速地加载到MySQL中,...二、实现再分析 对于单表20亿, 在MySQL运维,说真的这块目前涉及得比较少,也基本没什么经验,但对于InnoDB单表Insert 如果内存大于数据情况下,可以维持在10万-15万行写入。...Xtrabackup备份; 引入ZSTD压缩算法; 支持TokuDB的binlog_group_commit特性; 四、测试表 TokuDB核心配置: 表结构: 利用load data写入数据: 计算一下每秒写入速度...可以满足实际需求,另外对于磁盘IO比较好的机器(SSD类盘,云上的云盘),如果内存和数据差不多情况,这量级数据量测试在Innodb里需要添加自增列,可以在3个小多一点完成。...测试结论: 利用TokuDB在某云环境中8核8G内存,500G高速云盘环境,多次测试可以轻松实现57万每秒的写入量。

    92320

    Mysql 存储大数据量问题

    Mysql 单表适合的最大数据量是多少?...我们说 Mysql 单表适合存储的最大数据量,自然不是说能够存储的最大数据量,如果是说能够存储的最大量,那么,如果你使用自增 ID,最大就可以存储 2^32 或 2^64 条记录了,这是按自增 ID 的数据类型...(至于为什么 Mysql 选择 b+树而不是其他数据结构来组织索引,不是本文讨论的话题,之后的文章会讲到。)那么 B+树索引是如何影响 Mysql 单表数据量的呢?...这样数据量将更小。 拆分 分而治之——没有什么问题不能通过拆分一次来解决,不行就拆多次。 Mysql 单表存储的数据量有限。一个解决大数据量存储的办法就是分库分表。...如果统计的数据有一定的业务规则,如只会按用户维度去统计,如统计某个用户的订单量,那么对订单表的分片,其实可以采用按用户 id 来分片,如此就可以解决这类统计问题。但是这种方案不通用。

    2.4K20

    MySQL每秒57万的写入,带你飞~

    本文作者:吴炳锡 来源:https://yq.aliyun.com/articles/278034 一、需求 一个朋友接到一个需求,从大数据平台收到一个数据写入在20亿+,需要快速地加载到MySQL中,...计算一下每秒写入速度: ? 文件大小: ? 实际文件8.5G,写入TokuDB大小3.5G,只是接近于一半多点的压缩量。 对于20亿数据写入,实际测试在58分钟多点就可以完成。...可以满足实际需求,另外对于磁盘IO比较好的机器(SSD类盘,云上的云盘),如果内存和数据差不多情况,这量级数据量测试在Innodb里需要添加自增列,可以在3个小多一点完成。...测试结论: 利用TokuDB在某云环境中8核8G内存,500G高速云盘环境,多次测试可以轻松实现57万每秒的写入量。...另外测试几种场景也供大家参考: 如果在TokuDB中使用带自增的主键,主键无值让MySQL内部产生写入速度,下降比较明显,同样写入2亿数据,带有自建主键: ?

    69820

    数据量影响MySQL索引选择

    现象 新建了一张员工表,插入了少量数据,索引中所有的字段均在where条件出现时,正确走到了idx_nap索引,但是where出现部分自左开始的索引时,却进行全表扫描,与MySQL官方所说的最左匹配原则...{                   "considered_access_paths": [                     {                     //可以看到这边MySQL...      "join_execution": {         "select#": 1,         "steps": [         ]       }     }   ] } 增加表数据量...-- 接下来增大表的数据量 INSERT INTO `staffs` (`name`, `age`, `pos`, `add_time`) VALUES     ('July', 25, 'dev',...表数据量的大小,会影响索引的选择,具体的情况还是通过Explain和Optimizer Trace来查看与分析。

    1.5K20
    领券