Mysql query efficiency experiments with and without indexes

1. Environment preparation

The mysql server uses Thinkpad T480, the client uses Mac pro; mysql version is 8.0.33

Prepare to store several tables with different numbers, the table structure and row content are as follows, create an index for the 'key2' column of each table

create table test_100
(
    id   bigint auto_increment primary key,
    name varchar(32) not null,
    key1 varchar(32) not null,
    key2 varchar(32) not null,
    key3 varchar(32) not null,
    key4 varchar(32) not null
);

create index idx_key2
    on test_100 (key2);

 The following are all tables, and the numbers represent the number of row records stored in the table:

 The space occupied by each table after inserting data is as follows:

2. Start the test

Create entity and mapper for each table, I use Mbaits-plus to operate the database here

Write a test class. Considering the space, here is only a test method for a 100-line data table, and the others are similar:

	public void test100_all() {
		// 100行数据
		LambdaQueryWrapper<Test100> wrapper = new LambdaQueryWrapper<>();
		// 非索引列查询
		wrapper.eq(Test100::getKey1, "CbBxYcvaCq");
		long now = System.currentTimeMillis();
		test100Mapper.selectList(wrapper);
		System.out.println("100行-全表扫描：" + (System.currentTimeMillis() - now) + "ms");
	}

	public void test100_ref() {
		// 100行数据
		LambdaQueryWrapper<Test100> wrapper = new LambdaQueryWrapper<>();
		// 索引列查询
		long now = System.currentTimeMillis();
		wrapper.clear();
		wrapper.eq(Test100::getKey2, "aXQBEneQDA");
		test100Mapper.selectList(wrapper);
		System.out.println("100行-命中索引：" + (System.currentTimeMillis() - now) + "ms");
	}

Because the two methods of the same table are called at the same time, considering that mysql's page data cache will affect the query results, they are called in both orders. The test results are as follows:

Table Name	First full table and then index	Index first, then full table	Conclusion | Efficiency
test100	100 rows - full table scan: 165ms 100 rows - hit index: 39ms	100 rows - hit index: 171ms 100 rows - full table scan: 38ms	almost
test1000	1000 rows - full table scan: 142ms 1000 rows - hit index: 61ms	1000 rows - hit index: 175ms 1000 rows - full table scan: 74ms	almost
test10000	10,000 rows - full table scan: 269ms 10,000 rows - hit index: 67ms	Ten thousand rows - hit index: 148ms Ten thousand rows - full table scan: 32ms	almost
test100000	100,000 rows - full table scan: 194ms 100,000 rows - hit index: 40ms	100,000 rows - hit index: 225ms 100,000 rows - full table scan: 226ms	There is a difference
test1000000	1 million rows - full table scan: 837ms 1 million rows - hit index: 99ms	1 million rows - index hit: 162ms 1 million rows - full table scan: 593ms	obvious difference
test5000000	Five million rows - full table scan: 3237ms Five million rows - hit index: 49ms	Five million rows - index hit: 142ms Five million rows - full table scan: 2866ms	differ greatly
test10000000	10 million rows - full table scan: 5796ms 10 million rows - hit index: 72ms	10 million rows - hit index: 187ms 10 million rows - full table scan: 5639ms	differ greatly
test100000000	100 million rows - full table scan: timed out 100 million rows - hit index: 192ms	100 million rows - hit index: 164ms 100 million rows - full table scan: timed out	very big difference