製造誤差！
11時頃今朝、私は残りの部分よりも仕事、ビット線と猫でね。突然、上司が言っている大声でグループワーク、：APPの間違っています！
母ああ、これはそれだけで間違っていると言うことですので、あまりにも怖いですが、間違ったメッセージを言いませんでした。だから私はすぐにAPPに見えます。
これは本当に間違っているだけでなく、シンプルかつ500残忍な、あまりにも怖いです。
第二に、デバッグにローカル急いで！
ラインが間違っているので、我々は直接デバッグすることはできません、もちろん、すぐにローカルにから抜け出します！
1、コードが間違っている場合は？
すぐにローカルプロジェクトは、コードが間違っていたものではありませんかどうかを確認するために、対応するインターフェースへのアクセスを開始します。
まあ、ローカルコードとSQLが間違っていません！
2、SQLは間違いはありますか？
これは、テスト・データベースと本番データベーステーブルがどのような変更されませんか？
私はすぐに、再び上記のテストライブラリを実行するSQLを依頼することはできませんものを見るためにSQLに直接スプールかかった
質問を。EMM、結果は正しかったです。
それはホームオフィスであるため、生産ライブラリについては、それが測定できない - と、通常は最初にローカルで変更され、その後、テスト、および最終的にそれを再現します。しかし、緊急の必要があるかもしれない、直接生産に、これは言っているわけではありません。
この時点で、我々は最初の2点を描くことができます。
- コードは、ローカルプロジェクト通常の訪問ので、問題ありません。
実行がローカルライブラリとテストライブラリには問題はありませんので、SQLは、一時的に、問題ではありません。
3、推測〜
だから、このバグの出現は、上の直接最も可能性の高い誰か本番データベースのテーブルには、変更されている、と私はまた、SQLインタフェースを使用します！
第三に、私は何もしてそれを変更しませんです！
1、その理由を見つけます
SQLコードとテストに問題がなかったたため、唯一の生産ライブラリが確認されます。
案の定、すぐに、グループのボスとのインターフェイスは、何の問題も言いませんでした。上司は明らかに返信、フィールドを追加し、私はのSQLテーブルを使用して行う生産環境の表です。
2、深い理由
周りに戻ってきて、SQLのインターフェースを見て、それが使用する場所に応じてキーワードタグを検索します。一つだけの機能がタグに記載されていますので、このデータベース関数内を見て行きます。
機能ソース：
ここでは、と私たちは、すべてのどのような状況を知っていると信じています。
新しいタグ・フィールドの後の2つの表に結果のテーブルは、フィールドのタグ名が存在します。クエリは、テーブルの接頭辞に対応していないときや、MySQLの結果としては、最終的には、結果セットは、テーブル、そして最終的にエラーのタグフィールドであることを認識しません。
第四に、特定のエラーメッセージと概要
特定のエラーメッセージの1、
オリジナルのSQL仕様では、生産ラインのバグで、その結果、唯一の小さな問題です。
例外が封入されているので、サーバ戻るようにのみ異常なAPP（500）。私はこれを見て、ローカルだけで特定のエラーメッセージを取得するには、バグを再現。
エラーメッセージは単純明快です：フィールドリストの列「タグは」曖昧です。中国のフィールドタグはあいまいです。
2.概要：
- Soが SQLを書くことは非常にシンプルですが、我々はいくつかの規範に従わなければならないが、それは今間違っていない規範に問題、書き込み合わせではありませんが、また避け、将来のミスに言うことはできませんが、私は仕事の世話をする必要があります！
- そして、我々は〜グローバルな例外ハンドラを行うが、エラーメッセージを印刷したり、バックグラウンドにログインするか、単に特定のエラーメッセージこの時間aを見つけることができないようにしてくださいので、
余談：
もちろん、また原則とMySQLのコンポーネントのメカニズムを深く理解していないだけで書かれた仕様に合わせて、良い手のSQLを記述し、それに。例えば：バイナリログ、アンドゥ、InnoDBストレージエンジン、ロック、インデックスと取引など。
あなたは、深さのMySQLに知りたい場合は、今私はの出力に常に集中することができ、要約学習MySQLの方言[シリーズ]列を。