前段時間實現某一個功能，涉及到對數據表的查詢操作，經本地與測試環境測試過後都沒問題，這一過程貌似都很順利，想想是不是要下班了啦（雖然時間好像也不早了）,接著推入正式環境下進行最後的測試(心想應該不會有什麼問題吧，畢竟就只是對數據的查詢，而且都已經測試過了，數據也完好的輸出)；
最後….終於還是意想不到的事情發生了。。。
產品那邊說為何為何這麼慢，數據加載不出來。。。
根據產品那邊的反饋，我看了看相關程序，覺得應該沒問題呀，再看看表字段設計，發現了我加的那幾個字段有的應該要加上索引的但我沒加，加上去了，測試下還是幾乎一樣慢，幾乎數據加載不來。。。
再看了看測試環境下的一些配置文件與正式環境下的配置對比，也沒發現什麼問題呀，
找問題。。。。
(這時思維貌似是陷進了某個死角。。)
經過主管的細心排查終於發現問題出現在哪裡了。。。
原來是Model底層有個包含所有表名其主鍵的一個緩存文件搞的鬼（好像是程序執行時沒加載到進行，或者保存的時候沒保存成功到該緩存文件），導致程序每一次涉及到對表的操作是都是重新去服務器裡去查詢所有表，想想多可怕啊。。。
總結這個事情反應出了以下問題：
1.程序方面的邏輯判斷不夠嚴謹！
體現在如果以上的那個緩存文件加載失敗，或者數據保存到緩存文件不成功，在日志裡能夠體現出來，那是不是定位問題所產生的原因是不是更快、更精准了！
2.排查問題的思維方式太過於局限性！
貌似總是在一個層面上去思考問題，很難跳出當前的思維模式站在其它的角度去思考問題，這可能是自身的問題！(思維不夠靈活，或者說經驗不足)
3.對系統底層框架的實現原理不夠深入！
可能在日常的開發中比較繁忙，我們只是停留在使用某一個方法，並沒有去深入了解它的底層實現原理，
這樣的話出現問題了，搞的就比較被動！
對於以上總結可能還遠遠不夠，但重要的是一定要去閱讀源代碼！
代碼片段：
/**
* 生成表結構信息
*
* @param string $table
* @return
*/
public function tableInfo($table)
{
if (empty($table))
return false;
//只取主鍵,find(2)等自動匹配主鍵時使用
if (file_exists(BASE_DATA_PATH . '/cache/fields/_pk.php')) {
$this->fields = require(BASE_DATA_PATH . '/cache/fields/_pk.php');
} else {
$full_table = Db::showTables();
$_pk_array = array();
$count = strlen(C('tablepre'));
foreach ($full_table as $v_table) {
$v = array_values($v_table);
if (substr($v[0], 0, $count) != C('tablepre'))
continue;
$tb = str_replace(C('tablepre'), '', $v[0]);
$fields = DB::showColumns($tb);
foreach ((array) $fields as $k => $v) {
if ($v['primary']) {
$_pk_array[$tb] = $k;
break;
}
}
}
$this->fields = $_pk_array;
F('_pk', $_pk_array, 'cache/fields');
}
return $this->fields[$table];
}
