① 请问ASP.NET+sql，数据量60万条运行速度是否会很慢
呵呵，如果真的是一个数据表（table）中有60万条记录的话，同情你是肯定的了，对于sql本身对于处理大批量数据并没有特别好的机制，需要你编程来改善了。
我知道的改善主要有两点，一个是采用存储过程（将一些使用频率很高的算法或语句集合写成函数的形式，在服务器端运行），这个方法能够很有效的减少数据通讯流量，大大提高asp中的速度，但是对服务器的要求很高了。建议你可以分出一个数据服务器，配置高啊高一点，第二编程的时候尽量注意对于数据库的直接访问，多多采用缓存模式，减少数据库和带宽的负担。
最好的方法还是oracal数据库，它本身提供了很多处理海量数据的机制，可以大大提高速度。同时如果你对海量数据处理不太熟悉的话，建议去看看oracal的一些机制，保你收获无限（暴金）
② sql max和sum哪个速度快
这些集函数对空值的处理:比如count()集函数,它的处理空值为
count(*)-count(price) 其中count(*)为所有的价格,count(price)是标了价格的,所以减掉就等于没标价的了.
还有这些集函数不能使用WHERE ,只能用COMPUTER.
③ 影响数据库性能的主要因素有哪些
以MySQL为例：
影响数据库性能的主要因素总结如下：
1、sql查询速度
2、网卡流量
3、服务器硬件
4、磁盘IO
以上因素并不是时时刻刻都会影响数据库性能，而就像木桶效应一样。如果其中一个因素严重影响性能，那么整个数据库性能就会严重受阻。另外，这些影响因素都是相对的。
例如：当数据量并没有达到百万千万这样的级别，那么sql查询速度也许就不是个重要因素，换句话说，你的sql语句效率适当低下可能并不影响整个效率多少，反之，这种情况，无论如何怎么优化sql语句，可能都没有太明显的效果。
相关内容拓展：
1、SQL查询速度
风险：效率低下的SQL
2、网卡流量
风险：网卡IO被占满（100Mb/8=100MB）
方案：
①减少从服务器的数量。从服务器都要从主服务器上复制日志，所以，从服务器越多，网络流量越大。
②进行分级缓存。前方大量缓存突然失效会对数据库造成严重的冲击。
③避免使用“select * ”进行查询
④分离业务网络和服务器网络
3、磁盘IO
风险：磁盘IO性能突然下降。
方案：使用更好的磁盘设备解决。
④ 一条sql执行过长的时间，你如何优化，从哪些方面
1、查看sql是否涉及多表的联表或者子查询，如果有，看是否能进行业务拆分，相关字段冗余或者合并成临时表（业务和算法的优化）
2、涉及链表的查询，是否能进行分表查询，单表查询之后的结果进行字段整合
3、如果以上两种都不能操作，非要链表查询，那么考虑对相对应的查询条件做索引。加快查询速度
4、针对数量大的表进行历史表分离（如交易流水表）
5、数据库主从分离，读写分离，降低读写针对同一表同时的压力，至于主从同步，mysql有自带的binlog实现 主从同步
6、explain分析sql语句，查看执行计划，分析索引是否用上，分析扫描行数等等
7、查看mysql执行日志，看看是否有其他方面的问题
个人理解：从根本上来说，查询慢是占用mysql内存比较多，那么可以从这方面去酌手考虑
⑤ 为什么SQL处理数据比Java快
sql是一个专门处理数据的脚本，速度肯定比 java快啊！
⑥ 数据库牛人是如何进行SQL优化的
SQL 查询优化减少了查询所需的资源并提高了整体系统性能，在本文中，我们将讨论 SQL 查询优化、它是如何完成的、最佳实践及其重要性。
SQL 查询优化是编写高效的 SQL 查询，并在执行时间和数据库表示方面 提高查询性能 的迭代过程，查询优化是几个关系数据库管理系统 (RDBMS) 的一项重要功能。
查询是对来自数据库的数据或信息的问题或请求，需要编写一组数据库可以理解的预定义代码，结构化查询语言 (SQL) 和其他查询语言旨在检索或管理关系数据库中的数据。
数据库中的查询可以用许多不同的结构编写，并且可以通过不同的算法执行，写得不好的查询会消耗更多的系统资源，执行时间长，并可能导致服务损失，一个完美的查询可以减少执行时间并带来最佳的 SQL 性能。
SQL查询优化的主要目的是：
确保查询处于最佳路径和形式非常重要，SQL 查询过程需要最好的执行计划和计算资源，因为它们是 CPU 密集型操作，SQL 查询优化通过三个基本步骤完成：
解析确保查询在语法和语义上都是正确的，如果查询语法正确，则将其转换为表达式并传递到下一步。
优化在查询性能中扮演着重要的角色，并且可能很困难，任何考虑优化的查询执行计划都必须返回与之前相同的结果，但优化后的性能应该会有所提高。
SQL 查询优化包括以下基本任务：
最后，查询执行涉及将查询优化步骤生成的计划转化为操作，如果没有发生错误，此步骤将返回结果给用户。
一旦用户确定某个查询需要改进以优化 SQL 性能，他们就可以选择任何优化方法——优化 SQL 查询性能的方法有很多种，下面介绍了一些最佳实践。
提高查询性能的一种简单方法是将 SELECT * 替换为实际的列名，当开发人员在表中使用 SELECT * 语句时，它会读取每一列的可用数据。
使用 SELECT 字段名 FROM 而不是 SELECT * FROM 时，可以缩小查询期间从表中提取的数据的范围，这有助于提高查询速度。
循环中的 SQL 查询运行不止一次，这会显着降低运行速度，这些查询会不必要地消耗内存、CPU 能力和带宽，这会影响性能，尤其是当 SQL 服务器不在本地计算机上时，删除循环内的查询可提高整体查询性能。
使用SQL 服务器索引可以减少运行时间并更快地检索数据，可以使用聚集和非聚集 SQL 索引来优化 SQL 查询，非聚集索引单独存储，需要更多的磁盘空间，因此，了解何时使用索引很重要。
该OLAP功能“扩展了SQL解析函数的语法。” SQL 中的 OLAP 功能更快且易于使用，熟悉这些语法的 SQL 开发人员和 DBA 可以很容易地适应和使用它们。
OLAP 函数可以创建所有标准计算度量，例如排名、移动聚合、份额、期初至今、前期和未来期、平行期等。
查询优化器使用统计信息来确定如何最好地连接表、何时应该使用索引以及如何访问这些索引等，无论是手动还是自动，SQL 服务器统计信息都应该保持最新。
过时的 SQL Server 统计信息会影响表、索引或列统计信息，并导致查询计划性能不佳。
SQL 查询优化可以轻松提高系统性能，从而节省成本，优化 SQL 查询可以提高运营效率并加快性能，从而提高系统上线进度。
SQL 查询优化很重要，原因有很多，包括：
组织可以通过更快的响应时间获得可靠的数据访问和高水平的性能，优化 SQL 查询不仅可以提高整体系统性能，还可以提高组织的声誉，最终，SQL 查询优化的最佳实践帮助用户获得准确、快速的数据库结果。
⑦ sql语句联合查询 与 视图想比较的话，那个效率快，为什么。
sql效率比较快，存储过程的好处是不仅快且更安全，但移植性差。视图可以封装查询的复杂性，就像面向对象里类的概念一样。
⑧ sql语句太长有什么坏处吗
不能说坏处，有很多数据库本身的结构、算法就比较复杂，语句长是很正常的。只是同等效果的语句，尽量选择精简的。还有就是书写的格式，很重要，尽量多使用分行书写。语句的效率主要体现：
1、可读性，也就是再次查看、修改sql语句时，容易阅读。
2、执行效率，如一些重复分组、重复的计算，造成的语句执行速度缓慢。
⑨ SQL Server 与 MySQL 性能相差多大
SQL，在这里我理解成SQL Server。三者是目前市场占有率最高（依安装量而非收入）的关系数据库，而且很有代表性。排行第四的DB2（属IBM公司），与Oracle的定位和架构非常相似，就不赘述了。
如果要说明三者的区别，首先就要从历史入手。
Oracle：中文译作甲骨文，这是一家传奇的公司，有一个传奇的大老板Larry Elliswww.hbbz08.com ion。 Ellision 32岁还一事无成，读了三个大学，没得到一个学位文凭，换了十几家公司，老婆也离他而去。开始创业时只有1200美元，却使得Oracle公司连续12年销售额每年翻一番。
Oracle成立于1977年，早期的理论基础，反而来自于一篇IBM的论文《A Relational Model of Data for Large Shared Data Banks》【1】。作者CODD选取了关系代数的五种运算，并基于运算，架构了一种新型的数据存储模型。基于这种模型，Oracle成为了一个非常典型的关系数据库。因此也变的严谨、安全、高速、稳定，并且变的越来越庞大。
由于其诞生早、结构严谨、高可用、高性能等特点，使其在传统数据库应用中大杀四方，金融、通信、能源、运输、零售、制造等各个行业的大型公司基本都是用了Oracle，早些年的时候，世界500强几乎100%都是Oracle的用户。
MySQL ：MySQL的最初的核心思想，主要是开源、简便易用。其开发可追溯至1985年，而第一个内部发行版本诞生，已经是1995年。到1998年，MySQL已经可以支持10中操作系统了，其中就包括win平台。但依然问题多多，如不支持事务操作、子查询 、外键、存储过程和视图等功能。下图是一个截止至2006年的数据库市场占有率【2】：
图中可以看出，MySQL的爆发实际是在01、02年，尤其是02年发布的4.0 Beta版，正式选定InnoDB作为默认引擎，对事务处理能力及数据缓存能力有了极大的提高。同年4.1版开始支持子查询，至此MySQL终于蜕变成一个成熟的关系型数据库系统。05年的5.0版本又添加了存储过程、服务端游标、触发器、查询优化以及分布式事务功能，但同年被Oracle抄了后路，InnoDB被Oracle收编。08年，MySQL被Sun收购，09年，Oracle收购了Sun和MySQL。
由于MySQL的早期定位，其主要应用场景就是互联网开发。基本上，互联网的爆发成就了MySQL，LAMP架构风靡天下。而由于MySQL更多的的追求轻量、易用，以及早期的事物操作及复杂查询优化的缺失，在传统的数据库应用场景中，份额极少。
SQL Server：一提到SQL Server，大家一般都只想到Microsoft SQL Server，而非Sybase SQL Server。SQL Server最初是由Microsoft, Sybase and Ashton-Tate三家公司拦下的生意，是为IBM（又出现了）公司的OS/2操作系统开发的。随着OS/2项目的失败，大家也分道扬镳。 Microsoft自然转向自己的win操作系统，作为windows NT软件方案的一部分。而Sybase则专注于Linux/Unix方向的数据库开发。
MS SQL Server主要面向中小企业。其最大的优势就是在于集成了MS公司的各类产品及资源，提供了强大的可视化界面、高度集成的管理开发工具，在快速构建商业智能（BI）方面颇有建树。 MS SQL Server是MS公司在软件集成方案中的重要一环，也为WIN系统在企业级应用中的普及做出了很大贡献。
典型应用场景
关于“大型数据库”，并没有严格的界定，有说以数据量为准，有说以恢复时间为准。如果综合数据库应用场景来说，大型数据库应用有以下特点：海量数据、高吞吐量；复杂逻辑、高计算量，以及高可用性。从这点上来说，Oracle，DB2就是比较典型的大型数据库，Sybase SQL Server也算是吧。下面分别说明之前三种数据库的应用场景。
Oracle。Oracle的应用，主要在传统行业的数据化业务中，比如：银行、金融这样的对可用性、健壮性、安全性、实时性要求极高的业务；零售、物流这样对海量数据存储分析要求很高的业务。此外，高新制造业如芯片厂也基本都离不开Oracle；电商也有很多使用者，如京东（正在投奔Oracle）、阿里巴巴（计划去Oracle化）。而且由于Oracle对复杂计算、统计分析的强大支持，在互联网数据分析、数据挖掘方面的应用也越来越多。一个典型场景是这样的：
某电信公司（非国内）下属某分公司的数据中心，有4台Oracle Sun的大型服务器用来安装Solaris操作系统和Oracle并提供计算服务，3台Sun Storage磁盘阵列来提供Oracle数据存储，12台IBM小型机，一台Oracle Exadata服务器，一台500T的磁带机用来存储历史数据，San连接内网，使用Tuxedo中间件来保证扩展性和无损迁移。建立支持高并发的Oracle数据库，通过OLTP系统用来对海量数据实时处理、操作，建立高运算量的Oracle数据仓库，用OLAP系统用来分析营收数据及提供自动报表。总预算约750万美金。
MySQL。MySQL基本是生于互联网，长于互联网。其应用实例也大都集中于互联网方向，MySQL的高并发存取能力并不比大型数据库差，同时价格便宜，安装使用简便快捷，深受广大互联网公司的喜爱。并且由于MySQL的开源特性，针对一些对数据库有特别要求的应用，可以通过修改代码来实现定向优化，例如SNS、LBS等互联网业务。一个典型的应用场景是：
某互联网公司，成立之初，仅有PC数台，通过LAMP架构迅速搭起网站框架。随着业务扩张、市场扩大，迅速发展成为6台Dell小型机的中型网站。现在花了三年，终于成为垂直领域的最大网站，计划中的数据中心，拥有Dell机架式服务器40台，总预算20万美金。
MS SQL Server。windows生态系统的产品，好处坏处都很分明。好处就是，高度集成化，微软也提供了整套的软件方案，基本上一套win系统装下来就齐活了。因此，不那么缺钱，但很缺IT人才的中小企业，会偏爱 MS SQL Server 。例如，自建ERP系统、商业智能、垂直领域零售商、餐饮、事业单位等等。
1996年，Bill Gates亲自出手，从Borland挖来了大牛Anders，搞定了C#语言。微软02年搞定了http://ASP.NET。成熟的.NET、Silverlight技术，为 MS SQL Server赢得了部分互联网市场，其中就有曾经的全球最大社交网站MySpace，其发展历程很有代表性，可作为一个比较特别的例子【3】。其巅峰时有超过1.5亿的注册用户及每月400亿的访问量。应该算是MS SQL Server支撑的最大的数据应用了。
架构。其实要说执行的区别，主要还是架构的区别。正是架构导致了相同SQL在执行过程中的解释、优化、效率的差异。这里只做粗略说明，就不细说了：
Oracle： 数据文件包括：控制文件、数据文件、重做日志文件、参数文件、归档文件、密码文件。这是根据文件功能行进行划分，并且所有文件都是二进制编码后的文件，对数据库算法效率有极大的提高。由于Oracle文件管理的统一性，就可以对SQL执行过程中的解析和优化，指定统一的标准：
RBO（基于规则的优化器）、CBO（基于成本的优化器）
通过优化器的选择，以及无敌的HINT规则，给与了SQL优化极大的自由，对CPU、内存、IO资源进行方方面面的优化。
MySQL：最大的一个特色，就是自由选择存储引擎。每个表都是一个文件，都可以选择合适的存储引擎。常见的引擎有 InnoDB、 MyISAM、 NDBCluster等。但由于这种开放插件式的存储引擎，比如要求数据库与引擎之间的松耦合关系。从而导致文件的一致性大大降低。在SQL执行优化方面，也就有着一些不可避免的瓶颈。在多表关联、子查询优化、统计函数等方面是软肋，而且只支持极简单的HINT。
SQL Server ：数据架构基本是纵向划分，分为：Protocol Layer（协议层）， Relational Engine（关系引擎）， Storage Engine（存储引擎）， SQLOS。SQL执行过程就是逐层解析的过程，其中Relational Engine中的优化器，是基于成本的（CBO），其工作过程跟Oracle是非常相似的。在成本之上也是支持很丰富的HINT，包括：连接提示、
来源：知乎
着作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
⑩ sql语句中的select执行效率和where条件的排序有关吗
没有关系。
在MS
SQL
2008
R2下测试，一个数据量大约是20万条记录的表中，Where各条件前后放置查询速度基本一样。
MS
SQL内部是使用了很多查询优化算法的，并不是我们想象的，一条一条去比较，SQL的设计要是笨到那一步，就没法投入实际运用了。