1、数据库空间是个概述，在sqlserver里，使用语句 exec sp_spaceused 'TableName' 这个语句来查。
② sql数据量大的时候怎么优化
做分表优化呢，最后做好索引就行
③ 列举sql优化有哪些方式
sql优化的方式有：
1、选择最有效率的表名顺序(只在基于规则的优化器中有效)：
ORACLE 的解析器按照从右到左的顺序处理FROM子句中的表名，FROM子句中写在最后的表(基础表 driving table)将被最先处理，在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表作为基础表。如果有3个以上的表连接查询, 那就需要选择交叉表(intersection table)作为基础表, 交叉表是指那个被其他表所引用的表。
2、WHERE子句中的连接顺序：
ORACLE采用自下而上的顺序解析WHERE子句,根据这个原理,表之间的连接必须写在其他WHERE条件之前, 那些可以过滤掉最大数量记录的条件必须写在WHERE子句的末尾。
3、SELECT子句中避免使用 ‘ * ‘：
ORACLE在解析的过程中, 会将'*' 依次转换成所有的列名, 这个工作是通过查询数据字典完成的, 这意味着将耗费更多的时间 。
4、 减少访问数据库的次数：
ORACLE在内部执行了许多工作: 解析SQL语句, 估算索引的利用率, 绑定变量 , 读数据块等。
5、 在SQL*Plus , SQL*Forms和Pro*C中重新设置ARRAYSIZE参数, 可以增加每次数据库访问的检索数据量 ,建议值为200 。
6、 使用DECODE函数来减少处理时间：
使用DECODE函数可以避免重复扫描相同记录或重复连接相同的表。
7、整合简单,无关联的数据库访问：
如果你有几个简单的数据库查询语句,你可以把它们整合到一个查询中(即使它们之间没有关系)。
④ sql数据库 大数据量查询 优化!!
我搞过一个销售管理的网站,一些客户的浏览记录也很多.
后来我们用了按类型分表的方法.把一个很长的表分成了7个表,然后建立视图来把他们弄一起,当然SQL优化是少不了的,尽量减少join和left的次数,适当建立索引.
你朋友圈的话,建议你用Ajax,动态刷新,那么是否考虑在这一次刷新页面的时候在后台先准备好下一次的查询数据呢.因为这个是一段一段的,显示一段,然后准备下一段.
PS:我这只是个人建议,希望能帮到你
⑤ sql操作超大量条数据时如何优化
首先是表设计要合理，要合理使用分区，索引等工具。
再一个就是看你需求是什么，数据分布情况如何。
比如select * from table a where a.col1=1;
这个例子里面，假设表a有一亿数据量，在不考虑分区的情况下，col1的数据分布对检索效果影响极大，比如如果col1是有唯一约束的字段，那很简单，直接通过索引定位，检索时间基本上在毫秒级。
可如果col1是个状态字段，比如只有0，1两个值。而且两个数值分配均匀，那符合条件的检索结果就会有5000w，这时候什么办法都没有，最快的检索方式就是全表扫描。
所以，如果没有具体的示例，是没法解答你的问题的。
⑥ sql调优的几种方式
你好，
SQL优化的一些方法
1.对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。
2.应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描。
3.应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。
4.应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描。
5.in 和 not in 也要慎用，否则会导致全表扫描，
6.下面的查询也将导致全表扫描：
select id from t where name like '%abc%'
7.应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。
8.应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。
9.不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。
10.在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。
⑦ 开发中，SQL语句优化有哪些方法
看你数据库类型和框架是否支持。
一般开发中遇到慢SQL存在3个问题（索引健全的情况下）。
数据量多导致总行数慢，因为数据在不归档、迁移、转总账的情况下会不断积压。权限越高看见的数据量就越大，数据量越大总行数就越高。一般框架是以分页的SQL为基础计算总行数的。这样就会导致扫描行数高物理读高查询速度慢。优化方案就是总行数进行状态归档，以归档+实时的方式展现出来
连表超过多，部分数据表是单独的，但是不同部门的数据又有关联性，领导要看全生命周期或者流程数据的情况下必须多表相连。这样由于N个明细表导致笛卡儿积先不说，逻辑复杂连表多会消耗CPU，哪怕你查询能500毫秒内显示但是如果多人同时查就让CPU超100%甚至做成锁等待等堵塞。这个情况就是要用类似“云计算”的分布式计算。通过触发器、存储过程等规定时间内吧业务表数据计算好并写到展示表中，直接通过展示表进行关联，这样锁表也于业务表无关，关联表也能变少达到减少CPU消耗的目的。
iops与cpu占比高导致数据库瘫痪。第2点看出如果CPU高数据库全SQL都会慢，IOPS也一样。SQL慢会导致事务中的查询慢，解放事务变慢了其他查询就会锁等待状态变成堵塞。所以遇到大规模的查询是否先查主键然后通过游标一个一个计算再进临时表。这个是消耗时间和内存换CPU和IOPS的一个例子。反正服务器资源最高怎样开发应该是了解的，如何管制资源之间的平衡这个很重要。
举个例子，部分MYSQL框架喜欢一次性把数据库都导出来，然后减少子查询，这个算法针对有效的基础数据这样是可行的。针对业务数据应该没人会用，但是基础数据中也可能会存在海量的情况，比如坐标轨迹、省市区、电话号码归属等。如果无脑应用这个框架会导致查询起来很慢。
⑧ 列举sql优化有哪些方式方法 博客园
sql优化的方式有：
1、选择最有效率的表名顺序(只在基于规则的优化器中有效)：
ORACLE 的解析器按照从右到左的顺序处理FROM子句中的表名，FROM子句中写在最后的表(基础表 driving table)将被最先处理，在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表作为基础表。如果有3个以上的表连接查询, 那就需要选择交叉表(intersection table)作为基础表, 交叉表是指那个被其他表所引用的表。
2、WHERE子句中的连接顺序：
ORACLE采用自下而上的顺序解析WHERE子句,根据这个原理,表之间的连接必须写在其他WHERE条件之前, 那些可以过滤掉最大数量记录的条件必须写在WHERE子句的末尾。
3、SELECT子句中避免使用 ‘ * ‘：
ORACLE在解析的过程中, 会将'*' 依次转换成所有的列名, 这个工作是通过查询数据字典完成的, 这意味着将耗费更多的时间 。
4、 减少访问数据库的次数：
ORACLE在内部执行了许多工作: 解析SQL语句, 估算索引的利用率, 绑定变量 , 读数据块等。
5、 在SQL*Plus , SQL*Forms和Pro*C中重新设置ARRAYSIZE参数, 可以增加每次数据库访问的检索数据量 ,建议值为200 。
6、 使用DECODE函数来减少处理时间：
使用DECODE函数可以避免重复扫描相同记录或重复连接相同的表。
7、整合简单,无关联的数据库访问：
如果你有几个简单的数据库查询语句,你可以把它们整合到一个查询中(即使它们之间没有关系)。
⑨ 关于SQL数据库优化
具体要注意的：
1.应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：
select id from t where num is null
可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：
select id from t where num=0
2.应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。优化器将无法通过索引来确定将要命中的行数,因此需要搜索该表的所有行。
3.应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：
select id from t where num=10 or num=20
可以这样查询：
select id from t where num=10
union all
select id from t where num=20
4.in 和 not in 也要慎用，因为IN会使系统无法使用索引,而只能直接搜索表中的数据。如：
select id from t where num in(1,2,3)
对于连续的数值，能用 between 就不要用 in 了：
select id from t where num between 1 and 3
5.尽量避免在索引过的字符数据中，使用非打头字母搜索。这也使得引擎无法利用索引。
见如下例子：
SELECT * FROM T1 WHERE NAME LIKE ‘%L%’
SELECT * FROM T1 WHERE SUBSTING(NAME,2,1)=’L’
SELECT * FROM T1 WHERE NAME LIKE ‘L%’
即使NAME字段建有索引，前两个查询依然无法利用索引完成加快操作，引擎不得不对全表所有数据逐条操作来完成任务。而第三个查询能够使用索引来加快操作。
6.必要时强制查询优化器使用某个索引，如在 where 子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。如下面语句将进行全表扫描：
select id from t where num=@num
可以改为强制查询使用索引：
select id from t with(index(索引名)) where num=@num
7.应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如：
SELECT * FROM T1 WHERE F1/2=100
应改为:
SELECT * FROM T1 WHERE F1=100*2
SELECT * FROM RECORD WHERE SUBSTRING(CARD_NO,1,4)=’5378’
应改为:
SELECT * FROM RECORD WHERE CARD_NO LIKE ‘5378%’
SELECT member_number, first_name, last_name FROM members
WHERE DATEDIFF(yy,datofbirth,GETDATE()) > 21
应改为:
SELECT member_number, first_name, last_name FROM members
WHERE dateofbirth < DATEADD(yy,-21,GETDATE())
即：任何对列的操作都将导致表扫描，它包括数据库函数、计算表达式等等，查询时要尽可能将操作移至等号右边。
8.应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。如：
select id from t where substring(name,1,3)='abc'--name以abc开头的id
select id from t where datediff(day,createdate,'2005-11-30')=0--‘2005-11-30’生成的id
应改为:
select id from t where name like 'abc%'
select id from t where createdate>='2005-11-30' and createdate<'2005-12-1'
9.不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。
10.在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。
11.很多时候用 exists是一个好的选择：
select num from a where num in(select num from b)
用下面的语句替换：
select num from a where exists(select top 1 from b where num=a.num)
SELECT SUM(T1.C1)FROM T1 WHERE(
(SELECT COUNT(*)FROM T2 WHERE T2.C2=T1.C2>0)
SELECT SUM(T1.C1) FROM T1WHERE EXISTS(
SELECT * FROM T2 WHERE T2.C2=T1.C2)
两者产生相同的结果，但是后者的效率显然要高于前者。因为后者不会产生大量锁定的表扫描或是索引扫描。
如果你想校验表里是否存在某条纪录，不要用count(*)那样效率很低，而且浪费服务器资源。可以用EXISTS代替。如：
IF (SELECT COUNT(*) FROM table_name WHERE column_name = 'xxx')
可以写成：
IF EXISTS (SELECT * FROM table_name WHERE column_name = 'xxx')
经常需要写一个T_SQL语句比较一个父结果集和子结果集，从而找到是否存在在父结果集中有而在子结果集中没有的记录，如：
SELECT a.hdr_key FROM hdr_tbl a---- tbl a 表示tbl用别名a代替
WHERE NOT EXISTS (SELECT * FROM dtl_tbl b WHERE a.hdr_key = b.hdr_key)
SELECT a.hdr_key FROM hdr_tbl a
LEFT JOIN dtl_tbl b ON a.hdr_key = b.hdr_key WHERE b.hdr_key IS NULL
SELECT hdr_key FROM hdr_tbl
WHERE hdr_key NOT IN (SELECT hdr_key FROM dtl_tbl)
三种写法都可以得到同样正确的结果，但是效率依次降低。
12.尽量使用表变量来代替临时表。如果表变量包含大量数据，请注意索引非常有限（只有主键索引）。
13.避免频繁创建和删除临时表，以减少系统表资源的消耗。
14.临时表并不是不可使用，适当地使用它们可以使某些例程更有效，例如，当需要重复引用大型表或常用表中的某个数据集时。但是，对于一次性事件，最好使用导出表。
15.在新建临时表时，如果一次性插入数据量很大，那么可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果数据量不大，为了缓和系统表的资源，应先create table，然后insert。
16.如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先 truncate table ，然后 drop table ，这样可以避免系统表的较长时间锁定。
17.在所有的存储过程和触发器的开始处设置 SET NOCOUNT ON ，在结束时设置 SET NOCOUNT OFF 。无需在执行存储过程和触发器的每个语句后向客户端发送 DONE_IN_PROC 消息。
18.尽量避免大事务操作，提高系统并发能力。
19.尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理。
20. 避免使用不兼容的数据类型。例如float和int、char和varchar、binary和varbinary是不兼容的。数据类型的不兼容可能使优化器无法执行一些本来可以进行的优化操作。例如:
SELECT name FROM employee WHERE salary > 60000
在这条语句中,如salary字段是money型的,则优化器很难对其进行优化,因为60000是个整型数。我们应当在编程时将整型转化成为钱币型,而不要等到运行时转化。
21.充分利用连接条件，在某种情况下，两个表之间可能不只一个的连接条件，这时在 WHERE 子句中将连接条件完整的写上，有可能大大提高查询速度。
例：
SELECT SUM(A.AMOUNT) FROM ACCOUNT A,CARD B WHERE A.CARD_NO = B.CARD_NO
SELECT SUM(A.AMOUNT) FROM ACCOUNT A,CARD B WHERE A.CARD_NO = B.CARD_NO AND A.ACCOUNT_NO=B.ACCOUNT_NO
第二句将比第一句执行快得多。
22、使用视图加速查询
把表的一个子集进行排序并创建视图，有时能加速查询。它有助于避免多重排序 操作，而且在其他方面还能简化优化器的工作。例如：
SELECT cust.name，rcvbles.balance，……other columns
FROM cust，rcvbles
WHERE cust.customer_id = rcvlbes.customer_id
AND rcvblls.balance>0
AND cust.postcode>“98000”
ORDER BY cust.name
如果这个查询要被执行多次而不止一次，可以把所有未付款的客户找出来放在一个视图中，并按客户的名字进行排序：
CREATE VIEW DBO.V_CUST_RCVLBES
AS
SELECT cust.name，rcvbles.balance，……other columns
FROM cust，rcvbles
WHERE cust.customer_id = rcvlbes.customer_id
AND rcvblls.balance>0
ORDER BY cust.name
然后以下面的方式在视图中查询：
SELECT ＊ FROM V_CUST_RCVLBES
WHERE postcode>“98000”
视图中的行要比主表中的行少，而且物理顺序就是所要求的顺序，减少了磁盘I/O，所以查询工作量可以得到大幅减少。
23、能用DISTINCT的就不用GROUP BY
SELECT OrderID FROM Details WHERE UnitPrice > 10 GROUP BY OrderID
可改为：
SELECT DISTINCT OrderID FROM Details WHERE UnitPrice > 10
24.能用UNION ALL就不要用UNION
UNION ALL不执行SELECT DISTINCT函数，这样就会减少很多不必要的资源
35.尽量不要用SELECT INTO语句。
SELECT INOT 语句会导致表锁定，阻止其他用户访问该表。
上面我们提到的是一些基本的提高查询速度的注意事项,但是在更多的情况下,往往需要反复试验比较不同的语句以得到最佳方案。最好的方法当然是测试，看实现相同功能的SQL语句哪个执行时间最少，但是数据库中如果数据量很少，是比较不出来的，这时可以用查看执行计划，即：把实现相同功能的多条SQL语句考到查询分析器，按CTRL+L看查所利用的索引，表扫描次数（这两个对性能影响最大），总体上看询成本百分比即可。
今天在itput上看了一篇文章，是讨论一个语句的优化：
原贴地址： http://www.itpub.net/viewthread.php?tid=1015964&extra=&page=1
一，发现问题 优化的语句：
请问以下语句如何优化:
CREATE TABLE aa_001
( ip VARCHAR2(28),
name VARCHAR2(10),
password VARCHAR2(30) )
select * from aa_001 where ip in (1,2,3) order by name desc;
--目前表中记录有一千多万条左右，而且in中的值个数是不确定的。
以上就是优化的需要优化的语句和情况。
不少人在后面跟帖：有的说没办法优化，有的说将ＩＮ该为ＥＸＩＳＴＳ，有的说在ip上建立索引复合索引（ip，name)等等。
二，提出问题 那这样的情况，能优化吗，如何优化？今天就来讨论这个问题。
三，分析问题 1，数据量1千万多条。
2，in中的值个数是不确定
3.1 分析数据分布 这里作者没有提到ip列的数据的分布情况，目前ip列的数据分布可能有以下几种：
1，ip列（数据唯一，或者数据重复的概率很小）
2，ip列 (数据不均匀，可能有些数据重复多，有些重复少）
3，ip列 （数据分布比较均匀，数据大量重复，主要就是一些同样的数据（可能只有上万级别不同的ip数据等)
解决问题：
1，对于第一种数据分布情况，只要在ip列建立一个索引即可。这时不管表有多少行， in个数是不确定的情况下，都很快。
2，对应第二中数据分布情况，在ip列建立索引，效果不好。因为数据分布不均匀，可能有些快，有些慢
3，对应第三种数据分布情况，在ip列建立索引，速度肯定慢。
注意：这里的 order by name desc 是在取出数据后再排序的。而不是取数据前排序
对于2，3两个情况，因为都是可能需要取出大量的数据，优化器就采用表扫描(table scan)，而不是索引查找(index seek) ,速度很慢，因为这时表扫描效率要优于索引查找，特别是高并发情况下，效率很低。
那对应2，3中情况，如何处理。是将in改成exists。其实在sql server 2005和oracle里的优化器在in后面数据少时，效率是一样的。这时采用一般的索引效率很低。这时如果在ip列上建立聚集索引，效率会比较高。我们在SQL server 2005中做个测试。
表：[dbo].[[zping.com]]]中有约200万条数据。包含列Userid, id, Ruleid等列。按照上面的情况查询一下类似语句：
select * from [dbo].[[zping.com]]] where
userid in ('',''
,'') order by Ruleid desc
我们先看userid的数据分布情况，执行下面语句：
select userid,count(*) from [dbo].[[zping.com]]] group by userid order by 2
这时我们看看数据分布：总共有379条数据，数据两从1到15万都有，数据分布倾斜严重。下图是其中一部分。
这时如果在ip上建立非聚集索引，效率很低，而且就是强行索引扫描，效率也很低，会发现IO次数比表扫描还高。这时只能在ip上建立聚集索引。这时看看结果。
这时发现，搜索采用了（clustered index seek）聚集搜索扫描。
在看看查询返回的结果：
(156603 行受影响)
表 '[zping.com]'。扫描计数 8，逻辑读取 5877 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
表 'Worktable'。扫描计数 0，逻辑读取 0 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
返回15万行，才不到6千次IO。效率较高，因为这15万行要排序，查询成本里排序占了51%。当然可以建立（userid，Ruleid）复合聚集索引，提高性能，但这样做DML维护成本较高。建议不采用。
从上面的测试例子可以看出， 优化的解决办法：
数据分布为1：建立ip索引即可
数据分布为2，3：在ip列建立聚集索引。
⑩ SQL数据库优化的方法有哪些
在进行软件开发过程中，数据库的使用是非常重要的，但是数据库有很多种，不同数据库的使用方法是不同的。进行软件开发过程中，至少需要掌握一种数据库的使用方法。SQL数据库语法简单、操作方便和高效，是很多人最优的选择，但是SQL语句会受到不同数据库功能的影响，在计算时间和语言的效率上面需要进行优化，根据实际情况进行调整。下面电脑培训为大家介绍SQL数据库的优化方法。
一、适当的索引
索引基本上是一种数据结构，有助于加速整个数据检索过程。唯一索引是创建不重叠的数据列的索引。正确的索引可以更快地访问数据库，但是索引太多或没有索引会导致错误的结果。IT培训认为如果没有索引，处理速度会变得非常慢。
二、仅索引相关数据
指定需要检索数据的精度。使用命令*和LIMIT代替SELECT*。调整数据库时，必须使用所需的数据集而不是整个数据集，尤其是当数据源非常大时，指定所需的数据集，能够节省大部分时间。
三、根据需求使用或避免临时表
如果代码可以用简单的方式编写，那么永远不要使临时表变得复杂。当然，如果数据具有需要多个查询的特定程序，北大青鸟建议在这种情况下，使用临时表。临时表通常由子查询交替。
四、避免编码循环
避免编码循环是非常重要的，因为它会减慢整个序列的速度。通过使用具有单行的唯一UPDATE或INSERT命令来避免编码循环，并且昆明北大青鸟发现WHERE命令能够确保存储的数据不被更新，这样能够方便在找到匹配和预先存在的数据时被找到。