Reference: http://www.admin10000.com/document/13593.html
As the data size increases, so does the size of the index itself. Indexes are stored on disk as index files. Every time an index is read, there will be more I/O consumption (if a node is not read, an I/O consumption is required). Compared with memory consumption, I/O consumption is several orders of magnitude higher. In order to reduce I/O consumption, one way is to reduce the depth of the tree. Turn a binary tree into an m-ary tree. A B+Tree tree is a multi-way search tree. Understanding B+Tree pay attention to two aspects: 1) All data (keywords) are stored in leaf nodes, and non-leaf nodes do not store real data. 2) All leaf nodes are connected by pointers. The picture shows a simplified B+Tree with a height of 2.
Why does mysql set the node size to an integer multiple of the page?
According to the principle of disk storage, in order to reduce disk I/O, disks are often not read strictly on demand, but read ahead every time. The read-ahead length is generally an integer multiple of the page.
Pages are logical blocks of computer-managed memory. Hardware and OS tend to divide main memory and disk storage into contiguous equal-sized blocks, each of which is called a page. Main memory and disk exchange data in units of pages. A page fault exception is triggered when the data to be read by the computer is not in main memory. At this time, the system will send a disk read signal to the disk, the disk will find the starting position of the data and continuously read one or several pages back into the memory, then return an exception, and the program continues to execute.
MySQL uses this read-ahead principle to set the size of a node to a page. This allows each point to be fully loaded with only one I/O.
Although indexes can greatly improve query efficiency, maintenance still costs a lot, so indexes should be created reasonably.