- InnoDB supports transactions, which means strong business support better; can be rolled back, which means that some abnormal state can maintain stability. The MyISAM does not support, relatively speaking, better performance efficiency, only table lookup class more suitable for the engine.
- But the 5.5 version will start InnoDB as the default engine, more than 8 in the latest version, but canceled the MyISAM and InnoDB updated, optimized efficiency of InnoDB, MyISAM that nothing longer necessary.
- Recent problems when using MyIsql not cut AOP and transaction configuration problem, the problem is the result of MyISAM, stepped on a pit for a long time did not react, check for a long time to get to know.
- I used to think small is beautiful, is a good idea should soon change, at least not attained when stability is much more important than fast and small. At that time wanted to update a table your results are wrong, the investigation did not understand the online search meal, I felt really bad if the MyISAM InnoDB export convenient not know how much. And then also just want to fill the data entered, and, anyway, do a video with a project, people doing me doing chanting, write the results back to the first article database inside only to find the reality of just how much data to look.
- The last thing is that before still have to come out of the problem, aside enough duplicate items, and more change chew, I mostly 15 and 16-year pit in online search, the results up to now I'm still committed to see lagging behind the video do the project, really brain-dead.
Posted a question, I recently met, it is also very old:
A commodity stock, assuming only the last one, the inventory of 1, if at this time there are many people at the same purchase this how to do, it is impossible for two people under a single success, inventory -1 bar, so this in php + mysql specifically how to solve it?
Merchandise inventory information is not doing a single table and the table of merchandise information associated with better or just a good table? http://segmentfault.com/q/1010000002600161
Before electricity providers to do the project, they also run into this problem but at that time did not think carefully now so understand, I looked back and think this is the lock, the index above that he did not understand thoroughly.
And then paste I think a better solution:
-
Concurrent serial conversion, concurrent digestion queue or by similar means, a consumer sequentially background stock deduction
-
Concurrent & lock, the lock position may be mysql or any redis or write sever from other places
-
But in fact, there is an order to pay a certain success rate, so place orders on the card dead, then give up because the user may pay instead purchase large amounts, so there will be some non-technical issues need to be considered (oversold / stock after not sell / pay cut single tendency which?), this deduction stock concurrency problems do not necessarily occur when the next one
And in fact as a business platform I think 3 is the optimal solution, if it is their own doing, then play those two is a better choice, of course, can also deduct inventory left behind, plus a flow chart.
Of course, also involves the following answer to the redis memory plus persistence, but redis currently not learn to acquire it and see the effect of this change. Engineered solutions I also read: https://my.oschina.net/cart/blog/368690#OSC_h1_22
The first article, want to say, slowly.