Development and production combined with the daily summary Mysql database development and design principles are as follows:
- Try not to do database operations
Do not use as in mysql: md5 (), Order by Rand () function operation and the like of such
- Single table try to control the amount of data
After a single table of data is too large it will affect the efficiency of data query
2.1 Estimated amount of data a single table:
①. 纯INT不超过1000W
②. CHAR不超过500W2.2 at the same time to try to make reasonable points table:
通过USERID来分表（根据ID区间分表）
按DATE分表（按天、周、月分表）
按AREA分表（省、市、区分表）2.3 application scenarios partition table are:
① 表非常大，无法全部存在内存，或者只在表的最后有热点数据，其他都是历史数据；
② 分区表的数据更易维护，可以对独立的分区进行独立的操作；
③ 分区表的数据可以分布在不同的机器上，从而高效使用资源；
④ 可以使用分区表来避免某些特殊的瓶颈；
⑤ 可以备份和恢复独立的分区。- Avoid using NULL field
In the design of the database table field as much as possible all the time plus NOT NULL DEFAULT ''
3.1 difficult to query optimization
3.2 NULL Lie Jiasuo cited the need for additional space
3.3 containing NULL composite index is invalid
- Save picture is not in the database
If all the image database exists, such that the larger the volume of the database, will cause slower read and write.
Save a picture database of drawbacks:
Read the database / write speeds will never keep up with the speed of the file system processing
database backups become huge, more time-consuming
access to the file you need through the application layer and the database layer
- Reasonable care to add indexes
Adding an index to improve query
adding the index will slow to update
the index are not better
able to without the index as much as possible without (integrated assessment Data density and distribution of data, preferably not more than 20% of the number of fields)
combined with limited considering covering the core SQL index
- Do not index column operation
Index of the column to do arithmetic will lead to:
6.1 can not use the index
6.2 full table scan
1
2
- As far as possible without external key
7.1 foreign key can save development amount of
7.2 additional overhead
easy high concurrency deadlock 7.3
1
2
3
- Do not try to SELECT *
SELECT with time, will consume more CPU, memory, IO and network bandwidth, when we write the query, SELECT should try to do , just take the required data columns
- Avoid negative to a query and fuzzy query prefix%
In the actual development, we must try to avoid negative to a query, what is it negative to a query, mainly in the following:
NOT,! =, <>, ! <,!>, NOT EXISTS, NOT IN, NOT LIKE , etc.
1
At the same time, we have to avoid% prefix fuzzy query, because it would use the B + Tree, will also result in use can not be indexed, and will lead to full table scan, performance and efficiency can be imagined
- Reduce COUNT (*)
In development, we often use the COUNT (), not knowing that this usage will cause a lot of waste of resources, because the COUNT () large resource overhead, so we can do as little as possible
- GROUP BY ordering removal
GROUP BY using automatic sorting and grouping can be achieved
without having to sort: Order by NULL
particular ordering: Group by DESC / ASC
- Unified character set is UTF8, unified naming convention