Question

我有一个大约有100万行的表（物理磁盘上的大小几乎是8 GB，因为它有一个文本列），这需要花费大量时间进行任何事务。特别是对于“选择”，例如需要花费大量时间。计数查询大约需要20分钟，没有任何条件，即select count(*) from TestPerformance。

表架构是：

名称：TestPerformance

Field       Type    Null    Key     Default     Extra

ID      int(11)     NO  PRI     null    
TEXT        text        YES         null    
CATEGORY    varchar(100)    YES     MUL     null    
DDOMAIN     varchar(100)    YES         null    
NETWORK     varchar(100)    YES         null    
NODE        varchar(100)    YES         null    
ENTITY      varchar(100)    YES     MUL     null    
SEVERITY    int(11)     YES         null    
TTIME       bigint(20)  YES         null    
SOURCE      varchar(255)    NO  MUL     null    
HELPURL     varchar(100)    YES         null    
WEBNMS      varchar(100)    YES         null    
GROUPNAME   varchar(100)    YES         null    
OWNERNAME   varchar(25)     NO  PRI     null

和索引

Table           Non_unique  Key_name        Seq_in_index    Column_name     
TestPerformance     0       PRIMARY         1       ID      
TestPerformance     0       PRIMARY         2       OWNERNAME   
TestPerformance     1       TestPerformance0_ndx    1       ID      
TestPerformance     1       TestPerformance1_ndx    1       OWNERNAME   
TestPerformance     1       TestPerformance_ndx     1       CATEGORY    
TestPerformance     1       TestPerformance_ndx     2       SOURCE      
TestPerformance     1       TestPerformance_ndx1    1       ENTITY      
TestPerformance     1       TestPerformance_ndx2    1       SOURCE

我已将key_buffer大小调整为1 GB，但性能没有任何变化。

如何在不删除任何数据的情况下加快此表的交易？

我不是数据库专家。请提供您的建议，以提高表格的性能。

Answer 1

如何在不删除任何数据的情况下加快此表的交易？

100万行不很多数据。 8Gb是一个相当大的数据量。

将文本类型列移动到sperate表（具有1：1关系）。将这些varchar表的大小减小到保存数据所需的最小大小（或考虑将您不需要的任何内容移动到另一个表）。

您确实需要主键的和所有者名称吗？我怀疑id可能是独一无二的。如果是这样，丢失TestPerformance0_ndx - 这是多余的。实际上，您应该分析您的日志并查看DBMS实际需要哪些索引来为查询提供服务并相应地修改模式

Answer 2

在您的查询上运行EXPLAIN（您应该发布给我们查看）。这将有助于确定您的查询尝试使用哪些索引以及使用全表扫描的列。

此外，不要选择计数*，而是计算您的主要recid，以便它可以使用您的索引进行计数。

在MySQL中查询巨大的表

2 个答案: