① sql查詢和實體查詢那個查詢效率高
你說的實體查詢是什麼意思？ORM那些東西嗎？
如果是，那麼還是sql的效率高，很簡單，因為實體最終還是要轉化為sql去查詢。使用orm的意義，不在於提高你的執行效率，而在於提高你的開發效率，是要把非面向對象的sql操作，轉化為面向對象的實體操作。
② mysql資料庫的SQL語句和oracle的有什麼區別詳細點
區別如下：
1. Oracle是大型資料庫而Mysql是中小型資料庫，Oracle市場佔有率達40%，Mysql只有20%左右，同時Mysql是開源的而Oracle價格非常高。
2. Oracle支持大並發，大訪問量，是OLTP最好的工具。
3. 安裝所用的空間差別也是很大的，Mysql安裝完後才152M而Oracle有3G左右，且使用的時候Oracle佔用特別大的內存空間和其他機器性能。
4.Oracle也Mysql操作上的一些區別
①主鍵
Mysql一般使用自動增長類型，在創建表時只要指定表的主鍵為auto increment,插入記錄時，不需要再指定該記錄的主鍵值，Mysql將自動增長；Oracle沒有自動增長類型，主鍵一般使用的序列，插入記錄時將序列號的下一個值付給該欄位即可；只是ORM框架是只要是native主鍵生成策略即可。
②單引號的處理
MYSQL里可以用雙引號包起字元串，ORACLE里只可以用單引號包起字元串。在插入和修改字元串前必須做單引號的替換：把所有出現的一個單引號替換成兩個單引號。
③翻頁的SQL語句的處理
MYSQL處理翻頁的SQL語句比較簡單，用LIMIT 開始位置, 記錄個數；ORACLE處理翻頁的SQL語句就比較繁瑣了。每個結果集只有一個ROWNUM欄位標明它的位置, 並且只能用ROWNUM<100, 不能用ROWNUM>80
④ 長字元串的處理
長字元串的處理ORACLE也有它特殊的地方。INSERT和UPDATE時最大可操作的字元串長度小於等於4000個單位元組, 如果要插入更長的字元串, 請考慮欄位用CLOB類型，方法借用ORACLE里自帶的DBMS_LOB程序包。插入修改記錄前一定要做進行非空和長度判斷，不能為空的欄位值和超出長度欄位值都應該提出警告,返回上次操作。
⑤空字元的處理
MYSQL的非空欄位也有空的內容，ORACLE里定義了非空欄位就不容許有空的內容。按MYSQL的NOT NULL來定義ORACLE表結構, 導數據的時候會產生錯誤。因此導數據時要對空字元進行判斷，如果為NULL或空字元，需要把它改成一個空格的字元串。
⑥字元串的模糊比較
MYSQL里用 欄位名 like '%字元串%',ORACLE里也可以用 欄位名 like '%字元串%' 但這種方法不能使用索引, 速度不快。
③ 談談如何從本質上理解sql語句, 存儲過程，ORM之間的聯系和取捨。
所以我們需要來理解這些技術的本質。一，演變 剛開始的時候，只有sql語句，即可以用交互模式一句一句執行， 也可以用批模式執行，多行sql語句一次提交執行。 很快人們發現用批模式執行的一堆sql語言可以用過程的形式，事先存放到資料庫裡面，這就變成了存儲過程。 隨著面向對象技術的成熟，從程序中可以自動生成sql語句，這就是ORM 二，性能 很多人會說存儲過程比sql語句性能好，其實這個說法並不精確。 如果我們把一堆sql，以批的方式一次送入到伺服器，那麼伺服器，會對這一堆sql進行緩存，當下一次再度執行的時候，就好像調用一個」匿名「的存儲過程一樣。在這種情況下，性能差不多。 但是，如果我們不注意，很有可能，把可以一次提交的sql,變成了多次提交，甚至是每個循環做了一次提交，那麼性能就很差了。 也就是說如果使用sql,只要寫法得當，性能和sp區別不大。 同樣的道理，ORM的性能取決於ORM的Sql生成演算法， 和用戶使用的時候，對生成演算法的控制，比如利用好Lazy laoding等，在某些情況下，甚至可以不通過sql,畢竟沒有sql比最優化的sql還要快。三，可維護性 可維護性是選擇sql,sp,orm最主要的因素。 這裡面有點」玄「，因為不同的場景會得出不同的結論，俗稱「It depends" 剛開始的時候，sql的維護性看起來是最差，因為它往往散布在程序的每個角落。而存儲過陳都放在資料庫中，有清晰介面。 但是如果我們做一次重構，情況居然會顛倒過來。 首先，存儲過程完全可以照搬到C#中，sp的名字直接變成method的名字，sp的參數表直接變成method的參數表，（其實就是Command模式）。 其次，把這些methdod放到一個文件或者文件夾中。（所謂的DAL層，如果喜歡層的話） 通過這個重構，我們獲得了以下的好處， 1，首先是過程的調用和過程的定義放到了一起，修改起來比較方便。IDE都有定義跳轉功能。 2，過程的調用和定義同時進行版本控制，不會出現不匹配的情況。減少了sp的參數表和調用的不匹配，包括拼寫，類型，參數次序 3，單元測試非常方便 當然sp也有存在的價值，比如所謂的安全性，後面會提到。比如友好的調試環境，對於中小型項目，和初級程序員來說，也是很好的選擇。 ORM則將可維護性提升身到了一個新的高度，它試圖將sql屏蔽起來，在操作對象的同時，自動就把資料庫的事情給辦了。 ORM有兩種模式，一種是ActiveRecord, 一種是Datamapper，前者從資料庫中讀取定義，後者在程序中定義。不過由於前者往往用migration來生成資料庫，其實也是定義在程序裡面的。好的ORM都有"leaking"的設計，也就是留了個」後門「，讓你有機會用sql來控制。 微軟的linq從某個角度類說，也是一種ORM, 它的設計思想可能是因為它覺得寫sql語句比寫c#代碼效率高，所以提供直接在C#中寫sql語句的機制，再自動生成真正的sql。不過，ORM真正價值在於它可以在恰當的時候，完全拋棄sql,比如比如讀用cache,寫用queue。而微軟的linq，完全是「無厘頭」的風格，在O中用R的寫法，難道是RRM， 唯一的好處只是鎖定程序和程序員在微軟的平台上。 三，安全性 對企業來說，安全性有的時候比性能更重要，由於存儲過程在資料庫上多加了一道屏障，所以很多企業會把存儲過程作為首選。 ORM可以說是安全性最差的， 因為只有到程序運行起來，你才能知道，會產生什麼樣的sql。 但是保證安全有許多方法和方面，比如部署前的測試， 資料庫的備份，對表的許可權的設置。等。用sp來保證安全，只是多個選項中的一個。 在startup型企業中，高級程序員往往起到主導作用， 所以他們會不猶豫的選擇ORM。
④ orm為開發帶來了什麼樣的便捷
ORM的全稱是Object Relational Mapping，即對象關系映射，是隨著面向對象的軟體開發方法發展而產生的。面向對象（Object-Oriented）是當今企業級應用開發環境中的主流開發方法，關系資料庫是企業級應用環境中永久存放數據的主流數據存儲系統。當今企業級基於關系資料庫開發的信息系統越來越多，而在你打開每個信息系統的數據訪問層的時候，看到的幾乎都是近似相同模式的重復性的代碼。從軟體復用技術的角度來看，這部分完全可以抽取出來加以復用，用以改善軟體開發的生命周期，從而可有力保障在企業信息化建設中能及時的提供軟體產品並具有更可靠的質量，且使得軟體的開發和維護成本更低。這就是ORM的職責所在。也有人持不同意見，如ORM有性能損失。就讓我們來分析下。
首先，讓我們來做下比較，在同等條件同等數據量的情況，不使用ORM與使用ORM相比，顯然不使用ORM執行時間會快那麼一點點，但這點你很快就覺得沒什麼可值得驕傲的了：比如你在某次頁面數據交互中，因使用ORM執行時間用了200ms，而沒有使用ORM執行時間只須要190ms，提高了10ms啊！！！如果你做的是底層，提高的是CPU運算速度或者是I/O的速度，確實不賴。而這里是信息系統，這些在用戶面前根本就感覺不到，即使你用了210ms、220ms用戶也不關心這些，然而為了能夠提高這些微不足道的x毫秒，你卻要寫大量重復的代碼，不停的Ctrl+C/Ctrl+V，最後代碼日積月累，你的代碼行確實增加了，而且很快，日復一日，年復一年...恭喜，你終於成為一個代碼量超過x萬行的偉大的代碼民工(不享受農民工待遇的「高級高素質」IT民工)！其實通過Cache的實現，能夠實現對性能的調優。
其次，從項目周期和開發進度上來說，ORM無疑提供了最佳方案。對象映射可以使業務對象與資料庫分離，使資料庫層透明，開發人員真正的面向對象。ORM通過對開發人員隱藏SQL細節可以大大的提高生產力。沒有哪個項目不計成本，無限制拖延下去的，多數是盡少投入盡快完成，還要易維護。使用ORM可以大大降低學習和開發成本。實際開發中，真正對客戶有價值的是其獨特的業務功能，而不應該把大量時間花費在寫數據訪問、增刪改查(CRUD)方法、後期的Bug查找和維護上。在使用ORM後，ORM框架已經把資料庫變成了我們所熟悉的實體對象，我們只需了解面向對象開發就可以實現資料庫應用程序的開發，不需要浪費時間在SQL上。同時也可減少代碼量，減少數據層出錯機會。
再次，從職業生涯規劃和人員能力提升方面，ORM因為節省大量的開發時間，無疑可以讓開發人員有機會去做更有意義的事情，涉獵更多的知識。如果某人始終從事的都是這些模式重復的代碼開發，頂多就是個熟練工。
最後，從根本上講，當前信息系統開發基本上都是基於面向對象和關系資料庫的，而面向對象是從軟體工程基本原則(如耦合、聚合、封裝、繼承、多態)，而關系資料庫則是從數學理論（如關系模型、關系代數、關系運算、函數依賴）發展而來的，兩套理論存在顯著的區別。ORM就是為解決這個不匹配的現象而產生的。所以從某種意義講，在ORM還未完全普遍存在的情況下，這種CRUD，也為想進入IT行業的一些青年提供了入門的機會；如果某天ORM像SQL語句或程序的順序、分支、循環一樣普遍，這樣的IT從業者，何去何從還另當別論，然而國人大多數開發人員都是做CRUD的。
另外，Choice is only choice! 選不選擇ORM是你自己的事，選擇什麼的ORM工具也是你來make a decision。不選擇ORM你就不停的寫CRUD唄，每人同情你；選擇了ORM並且選擇了合適的ORM工具你就享受它給你帶來的益處吧。但如今很難定論那種工具才是最好的，各有優缺點。譬如面向對象與面向過程一樣，OO提出這些年了也很成熟了，但今天面向過程的開發依然不少，且薪酬待遇比OO開發的強多了。如果非要給好工具做個判斷，也許通用、兼容性、易學易用是個選擇的依據。當然你選擇所熟悉的，成員都能很好操作且能滿足項目的需要，也許對你而言就是好的。一個技術再好若你不熟悉或不能滿足你的特殊要求或你不用，對你也沒有什麼意義。當然這里不是說讓你固步自封，不去接觸新東西，恰恰相反而是要廣泛涉獵，深入理解，不要老在一個地方兜圈子。LING TO SQL很不錯，但是如果你用Oracle或Access、Sysbase、DB2...，卻選擇用LING TO SQL那就是你的事了；如果你想為每一種資料庫都使用特定的ORM工具，這也是你自己的決定。選擇一個工具重要的是你要能夠很好的駕駑它，為你所用，而不是讓你圍著它轉。
附註，EntitysCodeGenerate的設計是基於兩個原則，ORM和「帕累托法則」（也作「80/20或90/10法則」），也就是說：花比較少（10%-20%）的力氣就可以解決大部分（80%-90%）的問題，這樣通過ORM框架，就僅需要付出少數時間和精力來解決剩下的少部分問題，這無疑縮短了整個項目的開發周期同時又保證了質量。對於特別復雜或海量數據處理等的特殊情況，也提供了相應方案，可用DbCore+SQL/存儲過程來優化，實際中這部分在項目中所佔比例很小，有些時候如趕工搶佔先機，這部分也可以在項目後期優化。EntitysCodeGenerate可以和多種Web伺服器或應用伺服器良好集成，如今已經支持幾乎所有流行的資料庫。該工具最早一直是作者內部使用，並未公布，如今共享出來，歡迎交流，批評斧正！
轉載僅供參考，版權屬於原作者。祝你愉快，滿意請採納哦
⑤ mysql資料庫的SQL語句和oracle的有什麼區別詳細點
首先是大體一致的，只是分頁查詢時oracle用的偽列（rownum），mysql用的是limit，具體的可以網路一下分頁；
另外oracle對sql語句要求更為嚴格，而且oracle里變數較mysql更多點，oracle中有number型，有大數據類型，mysql沒得；
另外舉個例子，oracle不能插入為空列，而mysql是可以的（個人覺得，不知道正確與否）。還有他們兩者函數有不同之處，如轉日期函數oracle是to_date('要轉的字元串','格式') -- select to_date('2004-05-07 13:23:44','yyyy-mm-dd hh24:mi:ss') from al，而mysql是str_to_date('08/09/2008', '%m/%d/%Y'); -- 2008-08-09//都是針對字元串轉日期來的。
還有一點，我們常常希望主鍵可以自動增長，避免我們插入數據時的重復問題，但是oracle不能設置列自動增長，而mysql是可以的，oracle可以用序列加觸發器來解決自動增長問題達到與mysql一樣的效果。
總體來說百分之九十的sql語句是沒區別的。總體來說oracle的格式嚴格點，對有些字元型的還必須加單引號才能插入，mysql要求就沒這么多了。還有當向資料庫插入一個日期時，mysql可以直接插入成功，但是oracle需要先轉化為sql裡面的日期類型才行；oracle較mysql而言更安全，但是收費的，一般大公司用的多。oracle還有存儲過程和函數，觸發器這些這是mysql沒有的。大體就是這樣吧。