TP顯示1054錯誤原因剖析！字段名錯或表不存在該列？

著實令人佩服，再次碰到示以1054這般糟糕錯誤的TP！這東西實際上就是數(shù)據(jù)庫當(dāng)中的字段不符合要求，要么是表里面不存在這一列，要么源自你所寫的SQL出現(xiàn)錯誤，簡直會把人逼到抓狂。今日我就要拆分剖析、詳盡訴說如何整治這個問題，切勿弄些虛無縹緲、不切實際的理論，直接呈現(xiàn)切實有用的內(nèi)容！

TP顯示1054錯誤原因是什么

這下邊這個糟糕錯誤，十有八九是你在SQL語句里，把字段名寫錯了，或者數(shù)據(jù)庫表根本就不存在這一列，像你非要去查詢一個“user_age”字段，結(jié)果表里邊僅僅只有“age”這一列，數(shù)據(jù)庫不跟你發(fā)脾氣才怪呢！另外還有一種可能性，那就是表名拼寫出現(xiàn)了差錯，我就曾經(jīng)碰到過有人把“users”錯打成“user”，還一直都找不到問題所在的情況，簡直能將人給氣得發(fā)笑。

另一種情形是，在進行聯(lián)表查詢之際，字段歸屬處于不清晰的狀態(tài)。舉例來說呀，當(dāng)同時對用戶表以及訂單表展開查詢的時候，這兩個表當(dāng)中均存在著名為“id”的字段，倘若你并未指定表前綴，那么數(shù)據(jù)庫就會直接陷入迷茫的狀態(tài)！這情形呀，就如同是身處菜市場大聲呼喊“老王”，最終卻有八個攤主一道回過頭來，此時誰能夠知曉你所呼叫的究竟是哪一個呢？

如何快速定位TP顯示1054錯誤

先把完整SQL語句提取出來，將其打印出來，之后，把打印出來的完整SQL語句扔進數(shù)據(jù)庫工具里，開啟數(shù)據(jù)庫工具，使其運行一遍！不要再使用TP的鏈?zhǔn)讲僮髁搜剑苯诱{(diào)用fetchSql()方法，借助這個方法拿到原始SQL。在好些情況下，框架所具有的緩存會對判斷起到干擾作用，所以，要記得先清空SQL緩存，然后再進行測試 ！

重點查對在模型內(nèi)所定義的table屬性以及字段映射，曾有一回我熬夜直至凌晨三點，最終發(fā)覺是于模型里$field屬性里多撰寫了一個逗號，這般的低級錯誤著實令人苦惱，提議運用逐段注釋法來展開排查，首先將聯(lián)表查詢拆分成單表，把條件從句逐一去除，縮減至最小范圍便能夠找出元兇 ！

TP顯示1054具體解決步驟

1. 核對數(shù)據(jù)庫表結(jié)構(gòu)：

   DESC 你的表名;

確認(rèn)字段名、類型完全匹配，注意大小寫和下劃線！

2. 檢查模型定義：

要保證，沒有憑借自己的小聰明去設(shè)置$name、$field屬性，尤其是，千萬不要在模型當(dāng)中寫下那些根本不存在的字段。

3. 聯(lián)表查詢必須帶表別名：

   ->alias('a')
請你明確一下問題哦，比如對這段內(nèi)容進行潤色、根據(jù)其進行拓展等等，這樣我才能更準(zhǔn)確地按照要求改寫。僅這一句不太明確具體的改寫方向呢。  ->連接('訂單b','a的標(biāo)識等于b的用戶標(biāo)識') .  （這是按照一般理解簡單改寫，你看看是否符合需求，若不符合請進一步說明）
   ->field('a.name,b.price')

別偷懶不加別名，否則字段沖突時數(shù)據(jù)庫直接擺爛！

存在這樣一個案例，是老子最后放置的，某一回進行排查的時候，發(fā)現(xiàn)同事把create_time寫成了creat_time，僅僅少了一個字母這般情況，然而卻折騰了整個技術(shù)組長達兩小時時間，像這種伴隨著血與淚的教訓(xùn)，你們可得長點心了??！

你們于解決1054錯誤之際，還碰到過哪些奇特的做法，趕快在評論區(qū)展示出來，讓大家見識見識，點贊并轉(zhuǎn)發(fā)給那個老是寫錯SQL的倒霉同事！