最开始我创建了一张表：
-- auto-generated definition
create table phishtank_database
(
id int auto_increment
primary key,
phish_id int not null,
url varchar(2048) not null,
url_sha256 char(64) not null,
phish_detail_url varchar(2048) not null,
submission_time datetime not null,
verified varchar(255) not null,
verification_time datetime not null,
online varchar(255) not null,
target varchar(255) not null,
created_at timestamp default CURRENT_TIMESTAMP not null,
etag varchar(255) not null,
constraint url_sha256_unique
unique (url_sha256)
)
charset = utf8mb4;
因为为了保证 url 是唯一的，给 url_sha256 加了唯一约束，我是有一个 github action 定时抓取最新的 url 到数据库中的，已经执行了好几个月没有问题。但是突然最近疯狂报错，我一看是现在批量 insert 的速度太慢。我的批量 insert 模板就是：
insert ignore into phishing_intelligence.phishtank_database (phish_id, url, url_sha256, phish_detail_url, submission_time , verified, verification_time, online, target, etag) values (?, ?, ?, ?, ? , ?, ?, ?, ?, ?),(?, ?, ?, ?, ? , ?, ?, ?, ?, ?),......
我测试了单个 insert into 需要 2s 出头，有一次批量插入 300 余条记录花费了 18min 。
然后我看腾讯云控制台中有一次慢 sql 执行竟然扫描了 7 亿多行。
我很自然会想到由于是需要检查唯一索引 url_sha256 每次插入都需要全表扫描+重建索引。随着数据量增加（但其实现在这个表中也只有 10w 出头的行）执行时间逐渐变长。而且我现在手动执行一次上述 instert 语句然后在实时监控中看到每秒的 innodb_rows_read 在 10w+。
但是我转头一想，既然 url_sha256 是唯一索引，那我这条语句岂不是逻辑上可以分两步：
[ol]
如果按照上述逻辑的话是不是就不应该有大量全表扫描的操作了？难道是插入完毕后重建索引的操作需要大量的全表扫描？
[/ol]
原谅我数据库知识太欠缺了，我知道上面很多推测只是我片面认识的结果，希望能有大佬帮忙解答一下:
[ol]
[/ol]
