First optimization and your sql index;
; plus a second cache, memcached, redis
high above it is done after the third, or slow, or call the shots from the master copy master replication, separate read and write can be done at the application layer, the efficiency of can also be used party tools, third-party tools recommended atlas 360, others are either inefficient or unmaintained;
fourth If the above are done or slow, do not think to do segmentation, mysql own partition table first try this, your application is transparent, without changing the code, but sql statement needs to be done to optimize for the partition table, sql condition conditions to bring the partition of the column, so that queries to locate on a small partition otherwise, it will scan all partitions, partition table in addition there are some pit, where not much to say;
fifth if the above is done, then do first vertical split, in fact, the degree of coupling module according to your will a large system into smaller systems, which is a distributed system;
the sixth is the level of segmentation, for the large amount of data tables, this step is the most troublesome, the best test of skill level, to select a reasonable shar ding key, in order to have a good query efficiency, but also changes the table structure, do some redundancy, applications have to be changed, sql much as possible with sharding key, the location data up to a defined table search, instead of scanning all of the tables ; MySQL database to generally follow the evolution of this step, but also from low to high cost.
One might say that the first step in optimizing sql index and this goes without saying it?
Indeed, we all know, but in many cases, this step did not put in place, and even some only in accordance with sql to build the index, did not for sql optimization (shot yet?), But the simplest of additions and deletions check outside, want to implement a query, the query may write a variety of different statements, depending on your choice of engine, the distribution of data in tables, indexes, the database optimization strategy, the query locking strategy and other factors, the final query efficiency vary greatly; from the overall optimization to consider, sometimes after you optimize a statement, but other query efficiency is reduced, so to get a balance point;
even proficient in mysql, then, in addition to purely technical optimization, but also according to business surface to optimize the sql statement, in order to achieve optimal results;
you say you are and sql index has been the best yet?
to tell you the different engine optimization, good effect myisam read and write efficiency is poor, and it is this data storage format, and the index pointer lock policy related data which is stored in the order (InnoDB data storage clustered index), his index b the tree node is a pointer to the physical location of the data, so look up quickly, (InnoDB inode is stored primary key data, it is necessary to find in accordance with the second primary key);
MyISAM table lock, the read only inter are concurrent, between between writing and reading and writing (and reading between the insert can be concurrent, concurrent_insert to set parameters, perform periodic table optimization operation, there is no way to update the operation) is serial, so write up slowly, and the default write priority than the priority of read, write operation to the high came to be inserted before the read operation immediately go, if the bulk write, read requests cause starvation, so to set the read priority or how much policy enforcement read-after-write operation is set;
myisam Do not use the sql query time is too long, if the improper use strategies, can lead to write starve to death, so try to split the low query efficiency sql, innodb are generally row locks, this generally refers to sql used in the index when the line lock is added to the index, not added to the data record, if sql did not use the index, still locked table, mysql is between the reader can be complicated, and the ordinary select the lock is not required when encountered lock records check, using a consistent non-locking read snapshot, which is based on the database isolation level strategy will read rows that are locked snapshot, or other update statement read lock using a current read read the original line;
the case because the average read and write do not conflict, so the reader will not starve innodb situation, but also because when using an index using a row lock, small lock granularity, the same lock on the competition less, increases the concurrent processing, concurrent read and write so efficiency is very good, the problem is low resulting in the secondary to find the primary key index after the query efficiency;
PS: very strange, why innodb index leaf The deposit is the primary key node rather than the physical address pointer as the data stored mysism like it? If there is a physical address pointer does not need the secondary to find you, that is what I started wondering, according to think about the difference mysism and innodb data storage, you will understand, I will not waste of breath! So in order to avoid secondary innodb can use the index to find cover technique, the index can not be used to cover, and then expand on that index-based coverage to achieve the delay associated;
I do not know what is covered by the index, it is recommended you anyway to figure out how it was back thing! Do what you can to optimize your sql it! It is low cost, but is a time-consuming live, in case of need for technology and business are all familiar with, hard to optimize in order to achieve optimal results after optimization is immediate!
Links: https://www.zhihu.com/question/19719997/answer/81930332