Ten Suggestions in Database Development Management

Because it is mainly used to manage the database platform, it has had a lot of dealings with the relevant technical staff of various departments of the company. Then, I learned a lot about the concept of the database from the daily communication, if there are correct and wrong ones, we will list some common false ideas today:

1. When we find that the lock table is serious, we will immediately think of using Innodb. It seems that after the row-Level Lock of Innodb, we will not lock the table. There are not a few developers who hold this concept, in fact, they do not know that table locks will be generated in the case of complex sorting or where conditions.

2. If I find that the disk IO is too large, I will immediately think of sub-tables (this direction is good). But when I ask, the result is several thousand tables, the disk I/O pressure will decrease. In fact, table sharding does not solve the disk I/O problem. It can be combined with database sharding and table sharding, and then shared to different physical machines so that the disk I/O can be truly split and reduced.

3. Most application developers Define the table name very commonly, such as user. In fact, this is not good because during packet capture analysis, such a table name without features will make troubleshooting difficult.

4. Most application developers do not like to clean up historical data on a regular basis, but only store the data. No matter whether the data is cleared, the project data volume reaches a certain level. When cleaning the program again, the service is affected.

5. Some application developers lack control over the table data fields. It is terrible to put more than 100 fields in a table.

6. Some application developers simply put the most frequently-defined mediutext in the table and use the database for storage. In addition, the cold and hot data are put together, making them speechless.

7. application developers often run some strange join and nested subquery SQL statements, but they don't explain how many scan sets will be there. I have seen hundreds of millions of scan sets.

8. The MySQL trigger is too dependent, but it does not take into account the confusion of the business logic if the recovery operation is performed after the misoperation.

9. Many technical developers want to use the Innodb Transaction Server to guarantee the important charge-related projects. In fact, it is not necessary, in my projects, myisam is used for both fee-based reading and Premier League billing channels. It has been running for almost two years. So far, I have not found any issue where users are not allowed to charge the company.

10. Many developers prefer to use SQL statements such as Now (). In fact, they should try to get time for PHP programs. Because when you use binlog to recover from misoperation, you can understand what I mean.

1. InnoDB or MyISAM talk about MySQL storage engine Selection
2. Detailed description of MySQL three practical development knowledge
3. Several knowledge points that DB2 must understand