If the business can guarantee the uniqueness of the case, select Normal or better performance index
select id from T where k=5
First, we look
Query process
For the general index, the query after the first record to meet the conditions, you need to find the next record until he came to the first record 5 does not satisfy the condition of k =
For a unique index, because the index has a uniqueness, a query to the records meet the conditions after the stop retrieved
So here is the difference between a regular index will be more so check it, then this performance difference between the two is how much can it?
The answer is minimal, particularly at night it?
Because mysql when reading data, such as the one above statement, if not in memory, the disk will go to the entire data page k = 5 where this data are read into memory, the innodb, each data page the default size is 16KB, because the engine is read page by page, so that when k = 5 records found, when it in the pages of data in memory, and then for the general index, it should do more of that operation of a query, you only need to find one pointer and one calculation, of course, if K = 5 this record happens to be the last record the data page, then to remove a record, you must read the next page of data, this operation little more complicated, but for orthopedic field, a data page can put nearly a thousand key, therefore the probability of occurrence of this situation will be low, so when we calculate the average performance difference, throwing the operating costs can be considered for now cpu is negligible.
Update process
First, we say that under the concept of change_buffer, if you want to update the data in memory, then directly update the memory, if there is no data to be updated in memory, it will update the record in the presence change_buffer, wait until there is a query to read data page and they will perform change_buffe operate on this data page. In this way we can guarantee the correctness of the data logic.
change_buffer also persisted to disk, the operation will be applied to the original data in change_buffer page, get the latest result of a process known as merge, in addition to access the data page will trigger the merge, the system has a background thread periodically merge, the database normally closed in the process, will perform merge
Obviously if we can update records in change_buffer, reducing disk read speed of execution of the sentence will be significantly improved. Moreover, the data is read into memory need to occupy buffer pool, so in this way also can avoid occupying memory, improve memory utilization
So under what conditions can use changebuffer it?
For a unique index for each update must first determine whether the operation violates a unique constraint, for example, to insert (4,400) this record, we must first determine whether there is now the records in the table, and this must want the data page read into memory in order to determine, since all read into memory, then directly update the memory will be faster, there is no need to use the change buffer.
Therefore, the update can not use a unique index change buffer
change buffer using a buffer pool in memory, because they can not grow indefinitely, change buffer size can be dynamically set by parameters innodb_change_buffer_max_size, when this parameter is set to 50 to indicate change buffer size can only occupy the buffer pool 50%
Now we look if you want to insert a new record (4,400) in this table, then, innodb processing flow is what
The first is that this record to be updated target page in memory, then, innodb process is as follows:
- For unique indexes, finding a location between 3 and 5, to determine that there is no conflict, insert this value, the statement execution ends
- For the general index, finding positions 3 and 5, insert this value, the statement execution ends
It would appear that the general index and unique index on the updated impact statement performance difference, but a judge will only consume a small CPU time.
However, this is not the focus of our attention
In the second case, the record to be updated target page is not in memory, this time, the process is as follows:
- For a unique index, because the need to determine unique, so read from disk where the data pages into memory, to determine there is no conflict, inserting values, the end of the
- For the general index, the sucked update records in a change buffer, the end of the
Access to data from disk io involve random read into memory, it is one of the highest costs of operating inside the database. changebuffer because of reduced random disk access, so updates to enhance the performance will be very obvious
But the change buffer application scenarios only for Write Once Read Many small businesses, the probability of a page is accessed immediately after the finish is relatively small, this time using the effect changebuffer best, this business model is common billing category, logging class system.
Conversely, if the update mode after a business is finished immediately do a query, even if the conditions are satisfied, the update records in a change buffer, but after due immediately to access the data pages, Merge will immediately trigger the process, so random access io number does not decrease, but increased the maintenance costs of change buffer. So, for this business model is, change buffer but counterproductive.
So, if all behind updates are immediately associated with a query for the record, then you should turn off change buffer, while in other cases, change buffer can improve the performance update.
summary
If the business can ensure the uniqueness of a field and for how much is to write a multi-business model, it is still a good choice of ordinary index.