TP顯示1054錯(cuò)誤原因剖析！字段名錯(cuò)或表不存在該列？
著實(shí)令人佩服，再次碰到示以1054這般糟糕錯(cuò)誤的TP！這東西實(shí)際上就是數(shù)據(jù)庫當(dāng)中的字段不符合要求，要么是表里面不存在這一列，要么源自你所寫的SQL出現(xiàn)錯(cuò)誤，簡直會(huì)把人逼到抓狂。今日我就要拆分剖析、詳盡訴說如何整治這個(gè)問題，切勿弄些虛無縹緲、不切實(shí)際的理論，直接呈現(xiàn)切實(shí)有用的內(nèi)容！
TP顯示1054錯(cuò)誤原因是什么
這下邊這個(gè)糟糕錯(cuò)誤，十有八九是你在SQL語句里，把字段名寫錯(cuò)了，或者數(shù)據(jù)庫表根本就不存在這一列，像你非要去查詢一個(gè)“user_age”字段，結(jié)果表里邊僅僅只有“age”這一列，數(shù)據(jù)庫不跟你發(fā)脾氣才怪呢！另外還有一種可能性，那就是表名拼寫出現(xiàn)了差錯(cuò)，我就曾經(jīng)碰到過有人把“users”錯(cuò)打成“user”，還一直都找不到問題所在的情況，簡直能將人給氣得發(fā)笑。
另一種情形是，在進(jìn)行聯(lián)表查詢之際，字段歸屬處于不清晰的狀態(tài)。舉例來說呀，當(dāng)同時(shí)對(duì)用戶表以及訂單表展開查詢的時(shí)候，這兩個(gè)表當(dāng)中均存在著名為“id”的字段，倘若你并未指定表前綴，那么數(shù)據(jù)庫就會(huì)直接陷入迷茫的狀態(tài)！這情形呀，就如同是身處菜市場大聲呼喊“老王”，最終卻有八個(gè)攤主一道回過頭來，此時(shí)誰能夠知曉你所呼叫的究竟是哪一個(gè)呢？
如何快速定位TP顯示1054錯(cuò)誤
先把完整SQL語句提取出來，將其打印出來，之后，把打印出來的完整SQL語句扔進(jìn)數(shù)據(jù)庫工具里，開啟數(shù)據(jù)庫工具，使其運(yùn)行一遍！不要再使用TP的鏈?zhǔn)讲僮髁搜?，要直接調(diào)用fetchSql()方法，借助這個(gè)方法拿到原始SQL。在好些情況下，框架所具有的緩存會(huì)對(duì)判斷起到干擾作用，所以，要記得先清空SQL緩存，然后再進(jìn)行測試 ！
重點(diǎn)查對(duì)在模型內(nèi)所定義的table屬性以及字段映射，曾有一回我熬夜直至凌晨三點(diǎn)，最終發(fā)覺是于模型里$field屬性里多撰寫了一個(gè)逗號(hào)，這般的低級(jí)錯(cuò)誤著實(shí)令人苦惱，提議運(yùn)用逐段注釋法來展開排查，首先將聯(lián)表查詢拆分成單表，把條件從句逐一去除，縮減至最小范圍便能夠找出元兇 ！
TP顯示1054具體解決步驟
1. 核對(duì)數(shù)據(jù)庫表結(jié)構(gòu)：
DESC 你的表名;
確認(rèn)字段名、類型完全匹配，注意大小寫和下劃線！
2. 檢查模型定義：
要保證，沒有憑借自己的小聰明去設(shè)置$name、$field屬性，尤其是，千萬不要在模型當(dāng)中寫下那些根本不存在的字段。
3. 聯(lián)表查詢必須帶表別名：
->alias('a')
請你明確一下問題哦，比如對(duì)這段內(nèi)容進(jìn)行潤色、根據(jù)其進(jìn)行拓展等等，這樣我才能更準(zhǔn)確地按照要求改寫。僅這一句不太明確具體的改寫方向呢。 ->連接('訂單b','a的標(biāo)識(shí)等于b的用戶標(biāo)識(shí)') . （這是按照一般理解簡單改寫，你看看是否符合需求，若不符合請進(jìn)一步說明）
->field('a.name,b.price')
別偷懶不加別名，否則字段沖突時(shí)數(shù)據(jù)庫直接擺爛！
存在這樣一個(gè)案例，是老子最后放置的，某一回進(jìn)行排查的時(shí)候，發(fā)現(xiàn)同事把create_time寫成了creat_time，僅僅少了一個(gè)字母這般情況，然而卻折騰了整個(gè)技術(shù)組長達(dá)兩小時(shí)時(shí)間，像這種伴隨著血與淚的教訓(xùn)，你們可得長點(diǎn)心了??！
你們于解決1054錯(cuò)誤之際，還碰到過哪些奇特的做法，趕快在評(píng)論區(qū)展示出來，讓大家見識(shí)見識(shí)，點(diǎn)贊并轉(zhuǎn)發(fā)給那個(gè)老是寫錯(cuò)SQL的倒霉同事！