Sql MariaDB使用比较器结果创建表的速度非常慢（创建、选择、内部联接除外）

系统：

• Windows 10 64位
• 16GB内存
• 英特尔i5 4核3,2GHz

马里亚布

• V.10.5
• innodb_缓冲区_池_大小=4G
• UTF8
• InnoDB表

我有两个类似的表，每个表约有500k行：

CREATE TABLE `table1` (
    `column1` VARCHAR(256) NULL DEFAULT NULL COLLATE 'utf8_bin',
    `column2` VARCHAR(256) NULL DEFAULT NULL COLLATE 'utf8_bin',
    `column3` VARCHAR(2048) NULL DEFAULT NULL COLLATE 'utf8_bin',
    `column4` VARCHAR(32) NULL DEFAULT NULL COLLATE 'utf8_bin',
    `column5` VARCHAR(32) NULL DEFAULT NULL COLLATE 'utf8_bin',
    `column6` VARCHAR(32) NULL DEFAULT NULL COLLATE 'utf8_bin',
    `column7` VARCHAR(32) NULL DEFAULT NULL COLLATE 'utf8_bin',
    `column8` VARCHAR(32) NULL DEFAULT NULL COLLATE 'utf8_bin',
    `column9` VARCHAR(32) NULL DEFAULT NULL COLLATE 'utf8_bin',
    `column10` VARCHAR(32) NULL DEFAULT NULL COLLATE 'utf8_bin',
    `column11` VARCHAR(32) NULL DEFAULT NULL COLLATE 'utf8_bin',
    `column12` VARCHAR(32) NULL DEFAULT NULL COLLATE 'utf8_bin',
    `column13` VARCHAR(32) NULL DEFAULT NULL COLLATE 'utf8_bin',
    `column14` VARCHAR(32) NULL DEFAULT NULL COLLATE 'utf8_bin',
    `column15` VARCHAR(32) NULL DEFAULT NULL COLLATE 'utf8_bin',
    `import_by` VARCHAR(32) NULL DEFAULT NULL COLLATE 'utf8_bin',
    `import_date` DATETIME NOT NULL DEFAULT current_timestamp()
)
COLLATE='utf8_bin'
ENGINE=InnoDB
;

我还想比较这两个表的有效负载，并创建一个新的表与结果。它使用两个小样本表，但实际数据需要几个小时

前三列是标识符，第4-15列是有效负载。我需要一个可以看到有效负载变化的结果

现在我有一个小查询，它在小示例中工作：

SELECT 
    table2.column1,
    table2.column2,
    table2.column3,
    table2.column4 AS 'column4_new',
    table1.column4 AS 'column4_old',
    table2.column5 AS 'column5_new',
    table1.column5 AS 'column5_old',
    table2.column6 AS 'column6_new',
    table1.column6 AS 'column6_old',
    table2.column7 AS 'column7_new',
    table1.column7 AS 'column7_old',
    table2.column8 AS 'column8_new',
    table1.column8 AS 'column8n_old',
    table2.column9 AS 'column9_new',
    table1.column9 AS 'column9_old',
    table2.column10 AS 'column10_new',
    table1.column10 AS 'column10_old',
    table2.column11 AS 'column11_new',
    table1.column11 AS 'column11_old',
    table2.column12 AS 'column12_new',
    table1.column12 AS 'column12_old',
    table2.column13 AS 'column13n_new',
    table1.column13 AS 'column13_old',
    table2.column14 AS 'column14_new',
    table1.column14 AS 'column14_old',
    table2.column15 AS 'column15_new',
    table1.column15 AS 'column15_old'
    
FROM table2
INNER JOIN table1 
    ON 
    table2.column2 = table1.column2 
    AND 
    table2.column3 = table1.column3
    
EXCEPT
SELECT 

    table1.column1,
    table1.column2,
    table1.column3,
    table1.column4,
    table1.column4,
    table1.column5,
    table1.column5,
    table1.column6,
    table1.column6,
    table1.column7,
    table1.column7,
    table1.column8,
    table1.column8,
    table1.column9,
    table1.column9,
    table1.column10,
    table1.column10,
    table1.column11,
    table1.column11,
    table1.column12,
    table1.column12,
    table1.column13,
    table1.column13,
    table1.column14,
    table1.column14,
    table1.column15,
    table1.column15
    
FROM table1
INNER JOIN table2 
    ON 
    table1.column2 = table2.column2 
    AND
    table1.column3 = table2.column3;

我现在正在主机上运行查询

• 所有内核的CPU占用率为30-40%
• 内存总容量为4GB
• 硬盘驱动器占1%

首先，我不确定第1-3行的索引是否会使性能更好，但我明天会尝试。 有没有更简单的方法来获得这个结果？我想我走错了路，但我一点也不知道该怎么做

---

编辑

我清除了所有非布尔值（~100k行）并更改了collate。column2和column3现在位于一个全文索引中

编辑2：

因此，我现在尝试使用较小的数据集进行更改

全文键：

• 10万排花了36秒
• 2万排花了135秒

键：

• 2万排花了5秒
• 10万排花了27秒

解释（不使用创建表“xyz”）向我提供以下结果：

我试着重新思考我的过程。我不期望1，但也许它还能更快

INDEX(column2, column3)   -- (in either order)

然而，这个指数可能太大了。如果是那样的话，你有吗

INDEX(column2, column3(500))  -- in THAT order

请重新考虑列的大小和字符集。如果他们不需要像他们一样大，那么考虑缩小他们。特别是，如果

column3

可以是拉丁文1或ascii，则不需要前缀。索引有3072字节的限制；

2048

是字符，相当于utf8的6148字节

---

（32）列是UUID还是哈希？这可能会导致性能问题。提供更多信息，我会进一步讨论。

Mysql没有except运算符，所以这个问题不适用于Mysql。请为查询提供

EXPLAIN

。我明天会解释。优化表并创建索引als全文。第1-3列是VARCHAR，是一种组。我正在考虑为（column1、column2、column3）创建主键，但我不知道这是否有意义。@cr4nk89-a

主键必须是唯一的且
不能为NULL
。它的主要目的是唯一地标识每一行。它的第二个目的是作为一个索引。你现在没有PK了吗？如果
FULLTEXT
和
MATCH…country
与column3（或col2和col3的组合）配合良好，那么这可能是一个不错的选择。你能给我们更多关于专栏内容的线索吗？我试过有PK和没有PK。时间上没有差别。Col1-3是一种包含{a-Z和；和，和|和0-9}的唯一键。Col4-15现在仅为true、false和null。Col16-17已被删除。现在是70年代。
INDEX(column2, column3(500))  -- in THAT order