① 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没有的。大体就是这样吧。