1. External configuration optimization on statements:
1.1 There are many statements in the system log
Slow
query statement show_query_log = TRUE
show_query_file = /usr/local/mysql/slow_query_log.txt
show_query_time = 3
Execution planner:
EXPLAIN SELECT*FROM t;
explain select*from t ;
Use the execution planner, look at the time status, and judge the performance of SQL:
query data, there are field types, the best to worst are sorted by the following values (type):
system The best value
const The primary key is also the index
eq_ref link The query query condition is that the index
ref
ref_or_null link has a null value
all the worst value the
worst is all full table query The index implements the B-Tree or B+ query algorithm
based on another implicit data type data structure extracted from our data structure . 1.2 The joint index of MySQL version 5.1 and below is invalid: if the joint index is used only or the first field (the leftmost field) is used to participate in the query, the joint index will take effect: if the joint index is used without the first field to participate in the query, the joint index The index will fail: This screenshot shows that although mysql5.5 is slow, it still uses the index, and the higher version optimizes the index.
1.3 The joint index of mysql versions below 5.1 is invalid:
in the case of or, and or, both sides are a single index field, and the index does not take effect - a joint index can be used.
But version 5.6 and above is effective - adding index fields on both sides improves efficiency.
--EXPLAIN select *from m_member_table where name='zhangsan' or age= 24
is invalid when both sides of or (or one of the sides of or) are indexes -- a joint index can be used.
In versions 5.6 and above, index fields are added on both sides to improve efficiency.
In the case of and (or one side of and) a single index is valid. Remember this pit, and there is one or both index fields on both sides of and is valid.
1.4 The joint index of mysql version below 5.1 is invalid: like
like, regular query, sphinx sphinx search to speed up Chinese word segmentation and high-energy display.
When using like query, if the % symbol is in the first position, the index may not use
select * from t1 where name like "admin%" is used for the index
select * from t1 where name like "%admin" is not used. Do not use subqueries when querying
multiple tables. Because the subquery creates a temporary table, it is not only created but also destroyed.
2.
Simplify SQL: 1. Instead of using a subquery
, a subquery is to use the inner query result as an outer condition. When the subquery is executed, a temporary table is created in the disk, creating and Deleting temporary tables consumes resources.
Try to use join, or reduce select nesting
2. Add Chen Yu field
Try not to use join. For example, the order line table adds product information, and the order table adds the total amount.
3. Optimize server hardware:
1. Configure large memory
2. High-speed disk, reasonable allocation of disk, multi-core processor.
4. mysql parameter optimization:
the parameters should be combined with the data
engine . The bigger the better, the better, it depends on the memory size.
For example:
key_buffer_size: indicates the size of the index buffer. The index buffer is shared by all threads. Increasing the index buffer allows for better handling of indexes (for all reads and multiple rewrites), its size depends on the size of the memory, and if the value is too large, it causes the operating system to frequently page pages and also reduces performance.
sort_buffer_size: Indicates the size of the buffer allocated by each thread that needs to be sorted. Increasing the value of this parameter can improve the operation speed of Order by and Group by. The default value is 2M.
table_cache: Indicates the number of tables opened at the same time. The larger the value, the more tables can be opened. If the value is too large, too many tables can be opened at the same time, which will affect the performance of the operating system.
query_cache_size and query_cache_type
http://blog.csdn.net/jshuanghua/article/details/53858490
Execution planner: -- In-depth study
Also includes internal parameter optimization, server version, hardware, and business scenarios. Unique index, inject index.
Redis 3.0 and below cannot be used as a cluster, you can use master-slave and sentinel monitoring.
Redis 3.0 or above is used as a claub cluster.
Above reference: http://blog.csdn.net/zhuxineli/article/details/14455029
postgre reference: http://blog.csdn.net/chuan_day/article/details/45841345
explain ANALYZE, set enable_seqscan to false; object relation mapping (hidden The details of data access, sql is written in java splicing, reflection sacrifices performance, multiple tables are not enough) sub-database sub-table, as much as possible to achieve the same operation in one library. Sub-table generation ID problem 1. Dedicate a table to store self-incrementing IDs. 2. Use a consistent algorithm to calculate unique ID sub-tables according to different time or other business data values. Each table has the same structure, indicating that it is different. Extract the calculation rules for the indication, and before each query, calculate the table where the query result is located according to the business value. Before querying, you must specify the scope of the query, such as the time point. Sub- database 1. After switching the data source, aop configuration, post-processing, and automatic switching to the default data source. 2. According to the time 2015, 2016, different key names are selected, and the year parameter is passed in to dynamically cut the library. Sub-database sub-table rules: 1. Scope: The data is divided into n ranges, and the range of the record is calculated according to the business data. 2. Hash: Calculate the hashcode according to the business value, and then correspond to the specific database.
3. Predetermining a list value, such as dividing the library according
to
Problems: 1. How to solve the problem of paging between two libraries.
2. Query two tables, which are in different databases, and can only be queried twice. This problem cannot be avoided, so put a library for unified business as much as possible.
3. Cross-database service operations, using distributed things.
Summarize
your own implementation of sub-database sub-table
code clustered index and non-clustered index
http://blog.csdn.net/lijiaz5033/article/details/50129723
https://www.cnblogs.com/T8881/p/5940338.html