mysql表碎片化怎么看 mysql查看表碎片大小排序

怎么查看mysql数据库中的表是否损坏

可以使用语句检查表。如果结果的msg_text部分是好的，那么你的表是健康的。反之，则表明mysql数据库中的表有损坏。另外有些厉害的高手一额可以通过运行脚本来检测。

创新互联是一家专业的成都网站建设公司，我们专注成都网站设计、成都网站制作、网络营销、企业网站建设，买友情链接，1元广告为企业客户提供一站式建站解决方案，能带给客户新的互联网理念。从网站结构的规划UI设计到用户体验提高，创新互联力求做到尽善尽美。

MyISAM 表可以采用以下方法进行修复 ：使用 reapair table 或myisamchk 来修复。如果修复无效，采用备份恢复表。

阶段1 ：检查你的表

如果你有很多时间，运行myisamchk *.MYI 或myisamchk -e *.MYI 。使用-s （沉默）选项禁止不必要的信息。如果mysqld 服务器处于宕机状态，应使用--update-state 选项来告诉myisamchk 将表标记为' 检查过的' 。

你必须只修复那些myisamchk 报告有错误的表。对这样的表，继续到阶段2 。如果在检查时，你得到奇怪的错误( 例如out of memory 错误) ，或如果myisamchk 崩溃，到阶段3 。

阶段2 ：简单安全的修复

注释：如果想更快地进行修复，当运行myisamchk 时，你应将sort_buffer_size 和Key_buffer_size 变量的值设置为可用内存的大约25% 。

首先，试试myisamchk -r -q tbl_name(-r -q 意味着“ 快速恢复模式”) 。这将试图不接触数据文件来修复索引文件。如果数据文件包含它应有的一切内容和指向数据文件内正确地点的删除连接，这应该管用并且表可被修复。开始修复下一张表。否则，执行下列过程：

在继续前对数据文件进行备份。使用myisamchk -r tbl_name(-r 意味着“ 恢复模式”) 。这将从数据文件中删除不正确的记录和已被删除的记录并重建索引文件。

如果前面的步骤失败，使用myisamchk --safe-recover tbl_name 。安全恢复模式使用一个老的恢复方法，处理常规恢复模式不行的少数情况( 但是更慢) 。如果在修复时，你得到奇怪的错误( 例如out of memory 错误) ，或如果myisamchk 崩溃，到阶段3 。

阶段3 ：困难的修复

只有在索引文件的第一个16K 块被破坏，或包含不正确的信息，或如果索引文件丢失，你才应该到这个阶段。在这种情况下，需要创建一个新的索引文件。按如下步骤操做：

把数据文件移到安全的地方。使用表描述文件创建新的( 空) 数据文件和索引文件：

shell mysql db_name

mysql SET AUTOCOMMIT=1;

mysql TRUNCATE TABLE tbl_name;

mysql quit

如果你的MySQL 版本没有TRUNCATE TABLE ，则使用DELETE FROM tbl_name 。将老的数据文件拷贝到新创建的数据文件之中。回到阶段2 。现在myisamchk -r -q 应该工作了。你还可以使用REPAIR TABLE tbl_name USE_FRM ，将自动执行整个程序。

阶段4 ：非常困难的修复

只有.frm 描述文件也破坏了，你才应该到达这个阶段。这应该从未发生过，因为在表被创建以后，描述文件就不再改变了。

从一个备份恢复描述文件然后回到阶段3 。你也可以恢复索引文件然后回到阶段2 。对后者，你应该用myisamchk -r 启动。

如果你没有进行备份但是确切地知道表是怎样创建的，在另一个数据库中创建表的一个拷贝。删除新的数据文件，然后从其他数据库将描述文件和索引文件移到破坏的数据库中。这样提供了新的描述和索引文件，但是让.MYD 数据文件独自留下来了。回到阶段2并且尝试重建索引文件。

Mysql表分区状态查询

一、查询mysql表是否为分区表：可以查看表具有哪几个分区、分区的方法、分区中数据的记录数等信息

SELECT PARTITION_NAME,PARTITION_METHOD,PARTITION_EXPRESSION,PARTITION_DESCRIPTION,TABLE_ROWS,SUBPARTITION_NAME,SUBPARTITION_METHOD,SUBPARTITION_EXPRESSION

FROM information_schema.PARTITIONS WHERE TABLE_SCHEMA=SCHEMA() AND TABLE_NAME='xw_coobill_order';

二、查询表有多少个分区

SELECT TABLE_NAME, COUNT(*) AS CNT

FROM information_schema.PARTITIONS WHERE PARTITION_NAME IS NOT NULL

GROUP BY TABLE_NAME ORDER BY CNT DESC LIMIT 50;

三、分析执行语句

explain partitions select * from range_datetime where hiredate = '20151207124503' and hiredate='20151210111230';

四、分区管理

常规HASH和线性HASH的增加收缩分区的原理是一样的。增加和收缩分区后原来的数据会根据现有的分区数量重新分布。HASH分区不能删除分区，所以不能使用DROP PARTITION操作进行分区删除操作；

只能通过ALTER TABLE ... COALESCE PARTITION num来合并分区，这里的num是减去的分区数量；

可以通过ALTER TABLE ... ADD PARTITION PARTITIONS num来增加分区，这里是null是在原先基础上再增加的分区数量。

如何清理mysql数据库缓存数据？

1、打开mysql的客户端 这里使用navicat，连接数据库，等到navicat主页面，双击需要操作的数据库连接。

2、登录到数据库主页面后，点击左侧的数据库连接，打开数据库，可以看到可以操作的所有数据库。

3、这时有有两个数据库，目标是将数据1的所有数据同步到数据库2上，需要点击主页面上的。

4、打开工具菜单，选择数据库同步菜单，弹出数据同步的对话框，可以选择数据源，目标数据库。

5、选择数据库源和需要操作的数据库后，然后在选择目标数据库连接，目标数据库，然后在选择需要操作的表，点击开始即可。

php怎么显示mysql数据库的碎片？

MySQL 8.0.16 已经发布，它像往常一样增强了组复制 Group Replication 功能。

这篇文章介绍了 MySQL 8.0.16 为 Group Replication 带来的新功能：

Message fragmentation（信息碎片化）。

背景

Group Replication 目前使用 XCom（一种组通信引擎），特点：原子性，组员状态检测等。每个成员的组复制插件先将信息转发到本地 XCom，再由 XCom 最终以相同的顺序将信息传递给每个组成员的 Group Replication 插件。

XCom 由单线程实现。当一些成员广播信息过大时，XCom 线程必须花费更多的时间来处理那个大信息。如果成员的 XCom 线程忙于处理大信息的时间过长，它可能会去查看其他成员的 XCom 实例。例如，忙碌的成员失效。如果是这样，该组可以从该组中驱逐忙碌的成员。

MySQL 8.0.13 新增  group_replication_member_expel_timeout  系统变量，您可以通过它来调整将成员从组中驱逐的时间。例如，怀疑成员失败，但成员实际上忙于处理大信息，给成员足够的时间来完成处理。在这种情况下，是否为成员增加驱逐超时的设置是一种权衡。有可能等了很久，该成员实际真的失效了。

Message fragmentation（信息碎片化）

MySQL 8.0.16 的 Group Replication 插件新增用来处理大信息的功能：信息碎片化。

简而言之，您可以为成员的广播信息指定最大值。超过最大值的信息将分段为较小的块传播。

您可以使用  group_replication_communication_max_message_size  系统变量指定允许的信息最大值（默认值为10 MiB）。

示例

让我们用一个例子来解释新功能。图1显示了当绿色成员向组广播信息时，新功能是如何处理的。

图1 对传出信息进行分段

1. 如果信息大小超过用户允许的最大值（group_replication_communication_max_message_size），则该成员会将信息分段为不超过最大值的块。

2. 该成员将每个块广播到该组，即将每个块单独转发到XCom。

XCom 最终将这些块提供给组成员。下面三张图展示出了中间绿色成员发送大信息时工作的新特征。

图2a 重新组合传入的信息：第一个片段

3. 成员得出结论，传入的信息实际上是一个更大信息的片段。

4. 成员缓冲传入的片段，因为他们认为片段是仍然不完整的信息的一部分。（片段包含必要的元数据以达到这个结论。）

图2b 重新组合传入的信息：第二个片段

5. 见上面的第3步。

6. 见上面的第4步。

图2c 重新组合传入的信息：最后一个片段

7. 成员得出结论，传入的信息实际上是一个更大信息的片段。

8. 成员得出结论，传入的片段是最后一个缺失的块，重新组合原始信息，然后对其进行处理，传输完毕。

结论

MySQL 8.0.16 已经发布后，组复制现在可以确保组内交换的信息大小不超过用户定义的阈值。这可以防止组内误判而驱逐成员。