- InnoDBは、より良い、強力なビジネスサポートを意味し、トランザクションをサポートし、いくつかの異常状態が安定性を維持することができることをその手段、ロールバックすることができます。MyISAMテーブルは、比較的エンジンのために、より適した専用テーブルのルックアップクラス、優れた性能効率を話すサポートしていません。
- しかし、5.5バージョンでは、デフォルトのエンジンとして、最新バージョンでは8つ以上ののInnoDBを開始しますが、MyISAMテーブルをキャンセルし、InnoDBが更新され、InnoDBは、MyISAMテーブルの最適化された効率何がもはや必要という。
- MyIsqlカットではないAOPとトランザクション構成の問題を使用した場合、問題はMyISAMテーブルの結果である最近の問題は、知って取得するのに長い時間のために、チェックを反応しなかった長い時間のためにピットを踏ん。
- 私は小さいが綺麗だと思うために使用される、安定性がはるかに重要に高速かつ小型のよりときに得られず、少なくとも、すぐに変更する必要があります良いアイデアです。あなたの結果が間違っているテーブルを更新したかった調査は、オンライン検索の食事を理解していなかったのMyISAM InnoDBの輸出あればその時、私は便利などのくらいか分からない本当に悪い感じました。そしてまた、単に人々が内部だけどれだけのデータへの現実を見つけるために、結果は最初の記事データベースに書き戻し、私は詠唱やってやって、プロジェクトにビデオを行い、とにかく、入力されたデータを埋めるためにしたい、とあのね
- 最後は前にまだ、問題が出てくるために脇に十分な重複するアイテム、および複数の変更咀嚼を持っているということですが、私は主に15およびオンライン検索での16年のピット、私はまだコミットしています今すぐに結果までは確認してくださいビデオに遅れをとっすると、プロジェクト、本当に脳死を行います。
私は最近会った質問を、投稿、それはまた、非常に古いです：
このPHPのように、商品在庫は、この時点では、この方法を行うには、同じ購入で、多くの人々が存在する場合、1の在庫を最後のものだけを想定し、それには、2つの成功の下の人々、在庫-1バーのために不可能です+ MySQLの特にどのようにそれを解決するには？
商品在庫情報は、単一のテーブルとより良いに関連した商品情報のテーブルまたはちょうど良いテーブルをやっていないのですか？http://segmentfault.com/q/1010000002600161
電気プロバイダがプロジェクトを行う前に、彼らはまた、この問題が発生したが、その時ので、理解し、私は戻って見て、これがロックだと思う今、慎重に考えていなかった、それ以上のインデックスが、彼は徹底的に理解していませんでした。
そして、私はよりよい解決策を考えて貼り付けます。
-
同時シリアル変換、同時消化キューまたは同様の手段によって、消費者順次背景株式控除
-
コンカレント・ロック、ロック位置は、他の場所からのMySQLまたは任意のRedisまたは書き込みサーバであってもよいです
-
死んカードの発注は、ユーザーが代わりに支払う大量に購入する可能性があるため、その後あきらめて、そのいくつかの非技術的な問題は、（売られ過ぎ/株式検討する必要があるでしょうので、しかし、実際には、一定の成功率を支払うためには、そこにあります後の販売/賃金は？）単一の傾向をカットしていないとき、次のいずれか、この控除の株式並行性の問題は必ずしも発生しません。
そして、私は3が最適解だと思うビジネスのプラットフォームとして、実際に、それはやって自分のであれば、その後、遊ぶこれら二つがより良い選択である、もちろん、また控除在庫が残され、プラスフローチャートできます。
もちろん、また、Redisのメモリを加えた持続性を次のように答えを含むが、現在はそれを取得し、この変更の影響を確認するために学ぶことではないのRedis。私も読ん設計ソリューション：https://my.oschina.net/cart/blog/368690#OSC_h1_22
最初の記事は、ゆっくりと、言いたいです。