sql

存储过程里的递归调用传的是一个参数，这肯定不对 while(done = 0) do call iterateCategory(b); fetch c into b; end while;

同样求解，数据库知道的不多

select *from 表where recorddeal=recordtype

在使用PDA的过程中,发现数据库有数据,但是程序里面却看不到数据,程序没有问题,刚开始一直怀疑是程序的问题,但是其他的pda采用这套程序,使用过程中都没有出现这个问题 往上找了很多资料,和调试bug,问题一直没有解决. 经过多次寻找,产生的此问题的可能原因如下: 1.pda当前的年月日和数据库的对应表的时间对不上, 如pda没有同步时间的时,默认的时间是1970.1.1,如果只改了月和日,忽略了改年.结果导致数据库找不到对应的表,所以导致问题产生 2.在程序没有退出的过程中,即刻导入有数据的数据库,,程序一直在查询老表没有数据的数据库的过程中,会把新导入的数据库给删除掉,导致,重新登陆这个程序后,依然没有发现数据. 解决办法:先程序退出,然后把没有数据的数据库删除掉,重新导入有数据的数据库,打开软件, 禁止时间同步,即可!

varchar(n)长度为 n 个字节的可变长度且非 Unicode 的字符数据。n 必须是一个介于 1 和 8,000 之间的数值。存储大小为输入数据的字节的实际长度，而不是 n 个字节。nvarchar(n)包含 n 个字符的可变长度 Unicode 字符数据。n 的值必须介于 1 与 4,000 之间。字节的存储大小是所输入字符个数的两倍。

1.打开 Visual Studio 安装 media.2.在 WCUDAC 文件夹下， 找到这三个MSI文件: DACFramework_enu.msi, DACProjectSystemSetup_enu.msi, and TSqlLanguageService_enu.msi. 单独运行安装这三个文件。3.安装最新版本的 Visual Studio SP.

不需要这么麻烦。留下蔻蔻吧

你的什么版本？ 只有standard版本以上才有

如果我没记错。那个账号好像是在安装的时候创建的。你试着看看是不是。

select c.cname as 课成名, s.sname as 姓名,max(case when grade >=90 and grade <=100 then "A" when grade >=80 and grade <=89 then "B" when grade>=70 and grade<=79 then "C" else "D" end) as 成绩 from s,sc,c where s.s#=sc.s# and c.c#=sc.c# group by c.cname,s.sname,

这个是说，运行这些服务时用什么样的帐户。都选择Local Service帐户就可以了。最后一个，当别人在网络上浏览的时候，要不要显示你的机器，可以禁用。

首先查看是否支持该功能。 默认是关闭的，开启该功能。 查看开启状态。15表示历史缓存sql的个数。 接下来随便运行几条sql，并使用 show profiles 命令，将展示刚才运行的SQL语句。参数很好理解，不做解释了。 下面分析指定的SQL语句，使用如下命令(4是上面查出来的Query_ID，cpu和block io代表cpu的处理时间和io的时间)： 如果cpu时间慢，表示cpu的占用率比较高，io慢的话，表示内存占用率比较高。 其中cpu和block io两个参数比较重要，还有其他参数，如下： 在show profile 的时候有一个字段叫status，几个重要的参数如下： 除了上述几个字段，如果Status出现了如下几个字段，说明SQL性能问题很严重。

是不是用默认实例的问题 没用过2005 你看看安装的时候是默认的实例 现在你把实例名改下 改成主机名 应该就可以了 试试吧 不行的话 我明天上班做下实验

<tablewidth="250"id="mytalbe"style="background:url("images/b.gif")"><%WebApplicationContextwac=WebApplicationContextUtils.getWebApplicationContext(this.getServletContext());INoticeboardService<Noticeboard>noticeboardSer=(INoticeboardService)wac.getBean("noticeboardService");List<Noticeboard>noticeboradList=noticeboardSer.list("FromNoticeboardasnorderbyiddesc");//此处你取出的是第1条数据所以只显示一条，显示多条应该将此注释//Noticeboardnb=noticeboradList.get(0);%><tr><td><marqueedirection="up"height="300"onmouseout="this.start()"onMouseOver="this.stop()"scrollamount="2"><%//循环将消息显示for（inti=0;i<noticeboradList.size();i++）{Noticeboardnb=noticeboradList.get(i);%><%=nb.getContent()%><br/><%}%></marquee></td></tr></table>

因为ado ole db 提供程序，不允许多个结果等待一个连接，所以它会创建第二个连接执行命令，就会登入和登出，这多发生在执行聚合函数时，如果你恰好使用了聚合函数，那么本解决方案可能对你有用，就是用子查询的方式实现聚合函数的功能。

oracle10g的DBMS_XPLAN包中display_cursor函数不同于display函数，display_cursor用于显示SQL语句的真实的执行计划，在大多数情况下，显示真实的执行计划有助于更好的分析SQL语句的全过程，尤其是运行此SQL语句实时的I/O开销。通过对比预估的I/O与真实的I/O开销来判断SQL语句所存在问题，如缺少统计信息，SQL语句执行的次数，根据实际中间结果集的大小来选择合适的连接方式等。本文仅仅讲述display_cursor函数的使用。一、display_cursor函数用法1、display_cursor函数语法DBMS_XPLAN.DISPLAY_CURSOR(sql_idINVARCHAR2DEFAULTNULL,cursor_child_noINNUMBERDEFAULTNULL,formatINVARCHAR2DEFAULT"TYPICAL");2、display_cursor函数参数描述sql_id指定位于库缓存执行计划中SQL语句的父游标。默认值为null。当使用默认值时当前会话的最后一条SQL语句的执行计划将被返回可以通过查询V$SQL或V$SQLAREA的SQL_ID列来获得SQL语句的SQL_ID。cursor_child_no指定父游标下子游标的序号。即指定被返回执行计划的SQL语句的子游标。默认值为0。如果为null，则sql_id所指父游标下所有子游标的执行计划都将被返回。format控制SQL语句执行计划的输出部分，即哪些可以显示哪些不显示。使用与display函数的format参数与修饰符在这里同样适用。除此之外当在开启statistics_level=all时或使用gather_plan_statistics提示可以获得执行计划中实时的统计信息有关详细的format格式描述请参考：dbms_xplan之display函数的使用中format参数的描述下面给出启用统计信息时format新增的修饰符iostats控制I/O统计的显示last默认，显示所有执行计算过的统计。如果指定该值，则只显示最后一次执行的统计信息memstats控制pga相关统计的显示allstats此为iostatsmemstats的快捷方式，即allstats包含了iostats和memstatsrun_stats_last等同于iostatslast。只能用于oracle10gR1run_stats_tot等同于iostats。只能用于oracle10gR1抓一个最近一小时最消耗IO的SQL：SELECTsql_id,COUNT(*)FROMgv$active_session_historyash,gv$event_nameevtWHEREash.sample_time>SYSDATE-1/24ANDash.session_state="WAITING"ANDash.event_id=evt.event_idANDevt.wait_class="UserI/O"GROUPBYsql_idORDERBYCOUNT(*)DESC;执行上面的SQL：SQL>SELECTsql_id,COUNT(*)FROMgv$active_session_historyash,gv$event_nameevt23WHEREash.sample_time>SYSDATE-1/244ANDash.session_state="WAITING"5ANDash.event_id=evt.event_id6ANDevt.wait_class="UserI/O"7GROUPBYsql_id8ORDERBYCOUNT(*)DESC;SQL_IDCOUNT(*)-----------------------g7fu6qba82m6b66863r47zyphdk065269f5m4wd88nc1h514593p47drw5fhk232br91w16jzy4fu1204fvwyjpnh6tp778gm0nrbfuj8kzr702184k363hw4xd68gc4dajs7g5myy468vrk9sfuwfdgq42ccpnb4dwdmq2140查看SQL的执行计划：SELECT*FROMTABLE(dbms_xplan.display_cursor("g7fu6qba82m6b"));在SQLPLUS中执行：SQL>setpagesize2000SQL>SELECT*FROMTABLE(dbms_xplan.display_cursor("g7fu6qba82m6b"));PLAN_TABLE_OUTPUT------------------------------------------------------------------------------------------------------------------------SQL_IDg7fu6qba82m6b,childnumber0-------------------------------------UPDATE"CPDDS_PDATA"."CDM_LEDGER"SET"CSTM_NAME"=:a1,"CSTM_NO"=:a2,"PAPER_TYPE"=:a3,"PAPER_NO"=:a4,"CURR_TYPE"=:a5,"SVT_NO"=:a6,"BAL_DIR"=:a7,"BAL"=:a8,"AVAL_BAL"=:a9,"NORM_FRATIO"=:a10,"PK_BAL"=:a11,"DR_ACCU"=:a12,"CR_ACCU"=:a13,"LAST_TRAN_DATE"=:a14,"LAST_TRAN_TIME"=:a15,"PRT_LINE_NUM"=:a16,"NOREG_PK_REC_NUM"=:a17,"PK_NO"=:a18,"PWD"=:a19,"FLAG"=:a20,"FRZ_FLAG"=:a21,"CARD_HOLD_FLAG"=:a22,"PK_HOLD_FLAG"=:a23,"BGN_INT_DATE"=:a24,"OPEN_DATE"=:a25,"ACC_HOLD_FLAG"=:a26,"CLS_DATE"=:a27,"OPEN_TLR"=:a28,"CLS_TLR"=:a29,"CLS_INT"=:a30,"OPEN_INST"=:a31,"ADD_NUM"=:a32,"DAC"=:a33,"FRZ_TIMES1"=:a34,"FRZ_TIMES2"=:a35,"HOST_SEQNO"=:a36,"D_UPDATE_DATE"=:a37WHERE"ACC"=:b0Planhashvalue:319441092-----------------------------------------------------------------------------------|Id|Operation|Name|Rows|Bytes|Cost(%CPU)|Time|-----------------------------------------------------------------------------------|0|UPDATESTATEMENT||||3(100)|||1|UPDATE|CDM_LEDGER||||||*2|INDEXUNIQUESCAN|I_CDM_LEDGER|1|269|2(0)|00:00:01|-----------------------------------------------------------------------------------PredicateInformation(identifiedbyoperationid):---------------------------------------------------2-access("ACC"=:B0)29rowsselected.总结1、与display函数不同，display_cursor显示的为真实的执行计划2、对于format参数，使用与display函数的各个值，同样适用于display_cursor函数3、当statistics_level为all或使用gather_plan_statistics提示可以获得执行时的统计信息4、根据真实与预估的统计信息可以初步判断SQL效率低下的原因，如统计信息的准确性、主要的开销位于那些步骤等

检查程序的连接字符串,设定最大连接池并发数量,这个十之八九是程序的问题 另外服务器是否开启了审计功能,关闭试试.

select sname from student where sno = (select sno from sc where grade > (select grade from student, sc where sname = "刘晨" and Student.sno =sc.sno))

哪个不会说哪个吧。前面的应该都不难的

select a.ct-b.ct-c.ct from(select count(partyid) as ct from sc_student_info a,sc_mapip_floor b where a.building=b.building and a.floor=b.floor and b.ip="192.168.4.90") a,(select count(partyid) as ct from sc_login_trace where ip="192.168.4.90" and logindate="now") b,(SELECT count(a.studentid) as ct from sc_absent a,sc_student_info b,sc_mapip_floor c WHERE a.studentid=b.partyid AND b.building=c.building AND b.floor=c.floor and c.IP="192.168.4.90") c

SET ANSI_NULLS ONGOSET QUOTED_IDENTIFIER ONGOCREATE PROCEDURE sp_Getinfo @ag_sname nchar(10) --传递的参数ASBEGIN select 你想要的字段 from student a, course b, sc C where a.sno = c.sno and b.cno = c.cno and trim(a.sname) = @ag_sname --简单的链接，把参数写到语句里ENDGO--执行语句 EXEC sp_Getinfo "名字"

属性的意思呀

数据库监听在1521端口，防火墙禁用这个端口后，监听就会报错没法工作，当然也就无法远程连接了。不知道想实现什么样的效果

这个需要修改my.conf配置文件调整下连接数等更具体的直接百度下你发的关键字Out of memory

与DELPHI无关。数据库的表设计有一条重要规则，凡是可以通过表中数据运算可以得出的结果，都不要在表中另设字段。比如单价乘以数量等于金额，那么，金额这个字段就不就该在表中出现。由此可知，在SQL语句中，是可以进行数据运算的;比如表中如果已经有了出生日期这个字段，我们就不在需要年龄这段字段，但是用户在浏览查询的数据的时候，又需要看到年龄，因为谁也不愿意去根据出生年月来搬手指计算年龄。因此我们必须在显示数据的栅格表中添加一列，显示年龄，这个年龄就要在SQL语句中计算了。先在本代码段的BEGIN前面定义一个变量DQRQ:string;然后再代码段中给它赋值:dqrq:=dateTostr(date);这样我们就可以写如下SQL语句:"selectzyidas住院号,xmas姓名,ryrqas入院日期,(#"+dqrq+"#-csny)/365as年龄,"+"jgysas经管医生,cyrqas出院日期,zyfyas住院费用,"+"fycdzas费用承担者,jcrqas交出日期,scras收取人,"+"gdrqas归档日期,gdras归档人frombagdb"+"wherejcrqisnullandscrisnullandcyrqisnotnullandryhsisnotnull"+"ORDERBYcyrqasc";请注意“(#"+dqrq+"#-csny)/365as年龄”的写法。这是ACCESS的写法，SQLserver2000的写法有些不同。SQLserver2000的日期值是不需要#的，它的写法如:TB_BR_JB.RYRQBETWEEN"""+edit15.Text+"""AND"""+edit16.Text+"""";RYRQ(入院日期)在表中是日期型字段。

SQL数据库中的public是一个默认的用户角色。为便于管理数据库中的权限，SQL提供了若干“角色”，这些角色是用于对其他主体进行分组的安全主体。它们类似于MicrosoftWindows操作系统中的组。数据库级角色的权限作用域为数据库范围。每个SQLServer登录名均属于public服务器角色。如果未向某个服务器主体授予或拒绝对某个安全对象的特定权限，该用户将继承授予该对象的public角色的权限。当希望该对象对所有用户可用时，只需对任何对象分配public权限即可。但是，无法更改public中的成员关系。默认情况下，所有的数据库用户都属于public角色，因此赋予public角色的权限，所有的用户都会具备。

查找间于Date() 和 Date()-1的“信息”（你没列出）用a表.字段来排序。你可以用where data = ""来查询吗？不能的话就算了。

CREATE [UNIQUE] [CLUSTERED|NONCLUSTERED] INDEX index_name ON table_name (column_name…) [WITH FILLFACTOR=x]q UNIQUE表示唯一索引，可选q CLUSTERED、NONCLUSTERED表示聚集索引还是非聚集索引，可选q FILLFACTOR表示填充因子，指定一个0到100之间的值，该值指示索引页填满的空间所占的百分比

什么是索引拿汉语字典的目录页（索引）打比方：正如汉语字典中的汉字按页存放一样，SQL Server中的数据记录也是按页存放的，每页容量一般为4K 。为了加快查找的速度，汉语字（词）典一般都有按拼音、笔画、偏旁部首等排序的目录（索引），我们可以选择按拼音或笔画查找方式，快速查找到需要的字（词）。同理，SQL Server允许用户在表中创建索引，指定按某列预先排序，从而大大提高查询速度。• SQL Server中的数据也是按页（ 4KB ）存放• 索引：是SQL Server编排数据的内部方法。它为SQL Server提供一种方法来编排查询数据。• 索引页：数据库中存储索引的数据页；索引页类似于汉语字（词）典中按拼音或笔画排序的目录页。• 索引的作用：通过使用索引，可以大大提高数据库的检索速度，改善数据库性能。索引类型• 唯一索引：唯一索引不允许两行具有相同的索引值• 主键索引：为表定义一个主键将自动创建主键索引，主键索引是唯一索引的特殊类型。主键索引要求主键中的每个值是唯一的，并且不能为空• 聚集索引(Clustered)：表中各行的物理顺序与键值的逻辑（索引）顺序相同，每个表只能有一个• 非聚集索引(Non-clustered)：非聚集索引指定表的逻辑顺序。数据存储在一个位置，索引存储在另一个位置，索引中包含指向数据存储位置的指针。可以有多个，小于249个索引类型：再次用汉语字典打比方，希望大家能够明白聚集索引和非聚集索引这两个概念。唯一索引：唯一索引不允许两行具有相同的索引值。如果现有数据中存在重复的键值，则大多数数据库都不允许将新创建的唯一索引与表一起保存。当新数据将使表中的键值重复时，数据库也拒绝接受此数据。例如，如果在stuInfo表中的学员员身份证号(stuID) 列上创建了唯一索引，则所有学员的身份证号不能重复。提示：创建了唯一约束，将自动创建唯一索引。尽管唯一索引有助于找到信息，但为了获得最佳性能，建议使用主键约束或唯一约束。主键索引：在数据库关系图中为表定义一个主键将自动创建主键索引，主键索引是唯一索引的特殊类型。主键索引要求主键中的每个值是唯一的。当在查询中使用主键索引时，它还允许快速访问数据。聚集索引（clustered index）在聚集索引中，表中各行的物理顺序与键值的逻辑（索引）顺序相同。表只能包含一个聚集索引。例如：汉语字（词）典默认按拼音排序编排字典中的每页页码。拼音字母a，b，c，d……x，y，z就是索引的逻辑顺序，而页码1，2，3……就是物理顺序。默认按拼音排序的字典，其索引顺序和逻辑顺序是一致的。即拼音顺序较后的字（词）对应的页码也较大。如拼音“ha”对应的字(词)页码就比拼音“ba” 对应的字(词)页码靠后。非聚集索引(Non-clustered)如果不是聚集索引，表中各行的物理顺序与键值的逻辑顺序不匹配。聚集索引比非聚集索引（nonclustered index）有更快的数据访问速度。例如，按笔画排序的索引就是非聚集索引，“1”画的字（词）对应的页码可能比“3”画的字（词）对应的页码大（靠后）。提示：SQL Server中，一个表只能创建1个聚集索引，多个非聚集索引。设置某列为主键，该列就默认为聚集索引如何创建索引使用T-SQL语句创建索引的语法：CREATE [UNIQUE] [CLUSTERED|NONCLUSTERED] INDEX index_name ON table_name (column_name…) [WITH FILLFACTOR=x]q UNIQUE表示唯一索引，可选q CLUSTERED、NONCLUSTERED表示聚集索引还是非聚集索引，可选q FILLFACTOR表示填充因子，指定一个0到100之间的值，该值指示索引页填满的空间所占的百分比在stuMarks表的writtenExam列创建索引：USE stuDBGOIF EXISTS (SELECT name FROM sysindexes WHERE name = "IX_writtenExam") DROP INDEX stuMarks.IX_writtenExam /*--笔试列创建非聚集索引：填充因子为30％--*/CREATE NONCLUSTERED INDEX IX_writtenExam ON stuMarks(writtenExam) WITH FILLFACTOR= 30GO/*-----指定按索引 IX_writtenExam 查询----*/SELECT * FROM stuMarks (INDEX=IX_writtenExam) WHERE writtenExam BETWEEN 60 AND 90虽然我们可以指定SQL Server按哪个索引进行数据查询，但一般不需要我们人工指定。SQL Server将会根据我们创建的索引，自动优化查询。索引的优缺点• 优点– 加快访问速度– 加强行的唯一性• 缺点– 带索引的表在数据库中需要更多的存储空间– 操纵数据的命令需要更长的处理时间，因为它们需要对索引进行更新创建索引的指导原则• 请按照下列标准选择建立索引的列。– 该列用于频繁搜索– 该列用于对数据进行排序• 请不要使用下面的列创建索引：– 列中仅包含几个不同的值。– 表中仅包含几行。为小型表创建索引可能不太划算，因为SQL Server在索引中搜索数据所花的时间比在表中逐行搜索所花的时间更长

insert into 表名values()

create Index index_name on table_name(col1_name,col2_name...);注： 1.index_name ：你建立的索引名 2.table_name：你将要加索引的表名 3.col1_name:你要加索引的列名，从col1_name往后的列名都可以为空，如果不为空就变为组合索引。

示例；在表GoodsMade_Labour的SID列上创建唯一索引IX_GoodsMade_Labour，代码如下：create unique index IX_GoodsMade_Labour on GoodsMade_Labour(SID)这样情况下创建的是非聚集索引，它和使用nonclustered关键效果是一样的。create unique nonclustered index IX_GoodsMade_Labour on GoodsMade_Labour(SID)如果要创建聚集索引，可使用关键字clustered,代码如下：create unique clustered index IX_GoodsMade_Labour on GoodsMade_Labour(SID)

SQL SERVER中索引类型包括的三种类型分别是ufeffufeff唯一索引(UNIQUE)，聚集索引(CLUSTERED） ，非聚集索引(NONCLUSTERED）。主键与唯一索引的区别 主键是一种约束，唯一索引是一种索引，两者在本质上是不同的。 主键创建后一定包含一个唯一性索引，唯一性索引并不一定就是主键。 唯一性索引列允许空值，而主键列不允许为空值。 主键列在创建时，已经默认为空值 + 唯一索引了。 主键可以被其他表引用为外键，而唯一索引不能。 一个表最多只能创建一个主键，但可以创建多个唯一索引。 主键更适合那些不容易更改的唯一标识，如自动递增列、身份证号等。 在 RBO 模式下，主键的执行计划优先级要高于唯一索引。 两者可以提高查询的速度。

学习了~~

死锁，简而言之，两个或者多个trans，同时请求对方正在请求的某个对象，导致双方互相等待。简单的例子如下：trans1 trans2------------------------------------------------------------------------1.IDBConnection.BeginTransaction 1.IDBConnection.BeginTransaction2.update table A 2.update table B3.update table B 3.update table A4.IDBConnection.Commit 4.IDBConnection.Commit 那么，很容易看到，如果trans1和trans2，分别到达了step3，那么trans1会请求对于B的X锁，trans2会请求对于A的X锁，而二者的锁在step2上已经被对方分别持有了。由于得不到锁，后面的Commit无法执行，这样双方开始死锁。好，我们看一个简单的例子，来解释一下，应该如何解决死锁问题。-- Batch #1CREATE DATABASE deadlocktestGOUSE deadlocktestSET NOCOUNT ONDBCC TRACEON (1222, -1)-- 在SQL2005中，增加了一个新的dbcc参数，就是1222，原来在2000下，我们知道，可以执行dbcc --traceon(1204,3605,-1)看到所有的死锁信息。SqlServer 2005中，对于1204进行了增强，这就是1222。GO IF OBJECT_ID ("t1") IS NOT NULL DROP TABLE t1IF OBJECT_ID ("p1") IS NOT NULL DROP PROC p1IF OBJECT_ID ("p2") IS NOT NULL DROP PROC p2GOCREATE TABLE t1 (c1 int, c2 int, c3 int, c4 char(5000)) GODECLARE @x intSET @x = 1WHILE (@x <= 1000) BEGININSERT INTO t1 VALUES (@x*2, @x*2, @x*2, @x*2)SET @x = @x + 1ENDGOCREATE CLUSTERED INDEX cidx ON t1 (c1)CREATE NONCLUSTERED INDEX idx1 ON t1 (c2)GOCREATE PROC p1 @p1 int AS SELECT c2, c3 FROM t1 WHERE c2 BETWEEN @p1 AND @p1+1GOCREATE PROC p2 @p1 int ASUPDATE t1 SET c2 = c2+1 WHERE c1 = @p1UPDATE t1 SET c2 = c2-1 WHERE c1 = @p1GO上述sql创建一个deadlock的示范数据库，插入了1000条数据，并在表t1上建立了c1列的聚集索引，和c2列的非聚集索引。另外创建了两个sp，分别是从t1中select数据和update数据。 好，打开一个新的查询窗口，我们开始执行下面的query：-- Batch #2USE deadlocktestSET NOCOUNT ONWHILE (1=1) EXEC p2 4GO开始执行后，然后我们打开第三个查询窗口，执行下面的query：-- Batch #3USE deadlocktestSET NOCOUNT ONCREATE TABLE #t1 (c2 int, c3 int)GOWHILE (1=1) BEGININSERT INTO #t1 EXEC p1 4TRUNCATE TABLE #t1ENDGO开始执行，哈哈，很快，我们看到了这样的错误信息：Msg 1205, Level 13, State 51, Procedure p1, Line 4Transaction (Process ID 54) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.spid54发现了死锁。 那么，我们该如何解决它？在SqlServer 2005中，我们可以这么做：1.在trans3的窗口中，选择EXEC p1 4，然后right click，看到了菜单了吗？选择Analyse Query in Database Engine Tuning Advisor。2.注意右面的窗口中，wordload有三个选择：负载文件、表、查询语句，因为我们选择了查询语句的方式，所以就不需要修改这个radio option了。3.点左上角的Start Analysis按钮4.抽根烟，回来后看结果吧！出现了一个分析结果窗口，其中，在Index Recommendations中，我们发现了一条信息：大意是，在表t1上增加一个非聚集索引索引：t2+t1。5.在当前窗口的上方菜单上，选择Action菜单，选择Apply Recommendations，系统会自动创建这个索引。重新运行batch #3，呵呵，死锁没有了。这种方式，我们可以解决大部分的Sql Server死锁问题。那么，发生这个死锁的根本原因是什么呢？为什么增加一个non clustered index，问题就解决了呢？ 这次，我们分析一下，为什么会死锁呢？再回顾一下两个sp的写法：CREATE PROC p1 @p1 int AS SELECT c2, c3 FROM t1 WHERE c2 BETWEEN @p1 AND @p1+1 GOCREATE PROC p2 @p1 int ASUPDATE t1 SET c2 = c2+1 WHERE c1 = @p1UPDATE t1 SET c2 = c2-1 WHERE c1 = @p1GO很奇怪吧！p1没有insert，没有delete，没有update，只是一个select，p2才是update。这个和我们前面说过的，trans1里面updata A，update B；trans2里面upate B，update A，根本不贴边啊！那么，什么导致了死锁？需要从事件日志中，看sql的死锁信息：Spid X is running this query (line 2 of proc [p1], inputbuffer “… EXEC p1 4 …”): SELECT c2, c3 FROM t1 WHERE c2 BETWEEN @p1 AND @p1+1Spid Y is running this query (line 2 of proc [p2], inputbuffer “EXEC p2 4”): UPDATE t1 SET c2 = c2+1 WHERE c1 = @p1The SELECT is waiting for a Shared KEY lock on index t1.cidx. The UPDATE holds a conflicting X lock. The UPDATE is waiting for an eXclusive KEY lock on index t1.idx1. The SELECT holds a conflicting S lock.首先，我们看看p1的执行计划。怎么看呢？可以执行set statistics profile on，这句就可以了。下面是p1的执行计划SELECT c2, c3 FROM t1 WHERE c2 BETWEEN @p1 AND @p1+1|--Nested Loops(Inner Join, OUTER REFERENCES:([Uniq1002], [t1].[c1]))|--Index Seek(OBJECT:([t1].[idx1]), SEEK:([t1].[c2] >= [@p1] AND [t1].[c2] <= [@p1]+(1)) ORDERED FORWARD)|--Clustered Index Seek(OBJECT:([t1].[cidx]), SEEK:([t1].[c1]=[t1].[c1] AND [Uniq1002]=[Uniq1002]) LOOKUP ORDERED FORWARD)我们看到了一个nested loops，第一行，利用索引t1.c2来进行seek，seek出来的那个rowid，在第二行中，用来通过聚集索引来查找整行的数据。这是什么？就是bookmark lookup啊！为什么？因为我们需要的c2、c3不能完全的被索引t1.c1带出来，所以需要书签查找。 好，我们接着看p2的执行计划。UPDATE t1 SET c2 = c2+1 WHERE c1 = @p1|--Clustered Index Update(OBJECT:([t1].[cidx]), OBJECT:([t1].[idx1]), SET:([t1].[c2] = [Expr1004]))|--Compute Scalar(DEFINE:([Expr1013]=[Expr1013]))|--Compute Scalar(DEFINE:([Expr1004]=[t1].[c2]+(1), [Expr1013]=CASE WHEN CASE WHEN ...|--Top(ROWCOUNT est 0)|--Clustered Index Seek(OBJECT:([t1].[cidx]), SEEK:([t1].[c1]=[@p1]) ORDERED FORWARD) 通过聚集索引的seek找到了一行，然后开始更新。这里注意的是，update的时候，它会申请一个针对clustered index的X锁的。实际上到这里，我们就明白了为什么update会对select产生死锁。update的时候，会申请一个针对clustered index的X锁，这样就阻塞住了（注意，不是死锁！）select里面最后的那个clustered index seek。死锁的另一半在哪里呢？注意我们的select语句，c2存在于索引idx1中，c1是一个聚集索引cidx。问题就在这里！我们在p2中更新了c2这个值，所以sqlserver会自动更新包含c2列的非聚集索引：idx1。而idx1在哪里？就在我们刚才的select语句中。而对这个索引列的更改，意味着索引集合的某个行或者某些行，需要重新排列，而重新排列，需要一个X锁。SO………，问题就这样被发现了。总结一下，就是说，某个query使用非聚集索引来select数据，那么它会在非聚集索引上持有一个S锁。当有一些select的列不在该索引上，它需要根据rowid找到对应的聚集索引的那行，然后找到其他数据。而此时，第二个的查询中，update正在聚集索引上忙乎：定位、加锁、修改等。但因为正在修改的某个列，是另外一个非聚集索引的某个列，所以此时，它需要同时更改那个非聚集索引的信息，这就需要在那个非聚集索引上，加第二个X锁。select开始等待update的X锁，update开始等待select的S锁，死锁，就这样发生鸟。 那么，为什么我们增加了一个非聚集索引，死锁就消失鸟？我们看一下，按照上文中自动增加的索引之后的执行计划：SELECT c2, c3 FROM t1 WHERE c2 BETWEEN @p1 AND @p1+1|--Index Seek(OBJECT:([deadlocktest].[dbo].[t1].[_dta_index_t1_7_2073058421__K2_K1_3]), SEEK:([deadlocktest].[dbo].[t1].[c2] >= [@p1] AND [deadlocktest].[dbo].[t1].[c2] <= [@p1]+(1)) ORDERED FORWARD)哦，对于clustered index的需求没有了，因为增加的覆盖索引已经足够把所有的信息都select出来。就这么简单。实际上，在sqlserver 2005中，如果用profiler来抓eventid：1222，那么会出现一个死锁的图，很直观的说。下面的方法，有助于将死锁减至最少（详细情况，请看SQLServer联机帮助，搜索：将死锁减至最少即可。按同一顺序访问对象。 避免事务中的用户交互。 保持事务简短并处于一个批处理中。 使用较低的隔离级别。 使用基于行版本控制的隔离级别。 将 READ_COMMITTED_SNAPSHOT 数据库选项设置为 ON，使得已提交读事务使用行版本控制。使用快照隔离。使用绑定连接。

兄弟你索引的概念还不清楚吧,再去看看关于索引的内容建立索引的语句最主要的一句create index

你建数据库表的时候是不是把ID建成主键了？每个数据库表只允许有一个主键的。

在查询分析器里，选择数据库tempdb运行ALTER SERVICE MASTER KEY FORCE REGENERATE这个语句的功能是重新生成本地服务器的主密钥。打开：SQL Server Management Studio选择 数据库 -- 系统数据库 -- tempdb再点击 左上 菜单栏 “新建查询”在查询窗口中输入：ALTER SERVICE MASTER KEY FORCE REGENERATE点击“执行”OK这个语句的功能是重新生成本地服务器的主密钥重启SQL后 就不再出现这个错误日志了

create table table_namecolum_name datatype[constraint constraint_name] [not] null primary key |unique

自己打开企业管理器，随便找个表，导出一个创建表的脚本，就什么都有了。要语法，SQL的联机帮助里就有：CREATETABLE [database_name.[schema_name].|schema_name.]table_name({<column_definition>|<computed_column_definition>}[<table_constraint>][,...n]) [ON{partition_scheme_name(partition_column_name)|filegroup|"default"}] [{TEXTIMAGE_ON{filegroup|"default"}][;]<column_definition>::=column_name<data_type> [COLLATEcollation_name] [NULL|NOTNULL] [[CONSTRAINTconstraint_name]DEFAULTconstant_expression]|[IDENTITY[(seed,increment)][NOTFORREPLICATION] ] [ROWGUIDCOL][<column_constraint>[...n]]<datatype>::=[type_schema_name.]type_name [(precision[,scale]|max|[{CONTENT|DOCUMENT}]xml_schema_collection)]<column_constraint>::=[CONSTRAINTconstraint_name]{{PRIMARYKEY|UNIQUE}[CLUSTERED|NONCLUSTERED][WITHFILLFACTOR=fillfactor|WITH(<index_option>[,...n])][ON{partition_scheme_name(partition_column_name)|filegroup|"default"}] |[FOREIGNKEY]REFERENCES[schema_name.]referenced_table_name[(ref_column)][ONDELETE{NOACTION|CASCADE|SETNULL|SETDEFAULT}][ONUPDATE{NOACTION|CASCADE|SETNULL|SETDEFAULT}][NOTFORREPLICATION] |CHECK[NOTFORREPLICATION](logical_expression)}<computed_column_definition>::=column_nameAScomputed_column_expression[PERSISTED[NOTNULL]][ [CONSTRAINTconstraint_name] {PRIMARYKEY|UNIQUE}[CLUSTERED|NONCLUSTERED][WITHFILLFACTOR=fillfactor|WITH(<index_option>[,...n])] |[FOREIGNKEY]REFERENCESreferenced_table_name[(ref_column)][ONDELETE{NOACTION|CASCADE}][ONUPDATE{NOACTION}][NOTFORREPLICATION] |CHECK[NOTFORREPLICATION](logical_expression) [ON{partition_scheme_name(partition_column_name)|filegroup|"default"}]]<table_constraint>::=[CONSTRAINTconstraint_name]{ {PRIMARYKEY|UNIQUE}[CLUSTERED|NONCLUSTERED](column[ASC|DESC][,...n])[WITHFILLFACTOR=fillfactor|WITH(<index_option>[,...n])][ON{partition_scheme_name(partition_column_name)|filegroup|"default"}] |FOREIGNKEY(column[,...n])REFERENCESreferenced_table_name[(ref_column[,...n])][ONDELETE{NOACTION|CASCADE|SETNULL|SETDEFAULT}][ONUPDATE{NOACTION|CASCADE|SETNULL|SETDEFAULT}][NOTFORREPLICATION] |CHECK[NOTFORREPLICATION](logical_expression)}<index_option>::={ PAD_INDEX={ON|OFF} |FILLFACTOR=fillfactor |IGNORE_DUP_KEY={ON|OFF} |STATISTICS_NORECOMPUTE={ON|OFF} |ALLOW_ROW_LOCKS={ON|OFF} |ALLOW_PAGE_LOCKS={ON|OFF}}

CREATE [UNIQUE|CLUSTERED] INDEX INDEX_NAME ON TABLE_NAME(PROPERTY_NAME) 其中UNIQUE和CLUSTERED为可选项，分别是建立唯一索引和聚簇索引，具体解释为： UNIQUE:表示此索引的每一个索引值只对应唯一的数据。 CLUSTERED:表示要建立的索引时聚簇索引，即索引项的顺序与表中记录的物理顺序一致的索引组织。 希望采纳！

create index indexname on tabname(col1 ,col2 desc,....);

第一部分主要从数据结构及算法理论层面讨论MySQL数据库索引的数理基矗 第二部分结合MySQL数据库中MyISAM和InnoDB数据存储引擎中索引的架构实现讨论聚集索引、非聚集索引及覆盖索引等话题。 第三部分根据上面的理论基础，讨论MySQL中高性能使用索...

教科书上的B+Tree是一个简化了的，方便于研究和教学的B+Tree。然而在数据库实现时，为了更好的性能或者降低实现的难度，都会在细节上进行一定的变化。下面以InnoDB为例，来说说这些变化。04 - Sparse Index中的数据指针 在“由浅入深理解InnoDB索引的实现(1)”中提到，Sparse Index中的每个键值都有一个指针指向所在的数据页。这样每个B+Tree都有指针指向数据页。如果数据页进行了拆分或合并操作，那么所有的B+Tree都需要修改相应的页指针。特别是Secondary B+Tree(辅助索引对应的B+Tree), 要对很多个不连续的页进行修改。同时也需要对这些页加锁，这会降低并发性。为了降低难度和增加更新(分裂和合并B+Tree节点)的性能，InnoDB 将 Secondary B+Tree中的指针替换成了主键的键值。这样就去除了Secondary B+Tree对数据页的依赖，而数据就变成了Clustered B+Tree(簇索引对应的B+Tree)独占的了。对数据页的拆分及合并操作，仅影响Clustered B+Tree. 因此InnoDB的数据文件中存储的实际上就是多个孤立B+Tree。 一个有趣的问题: 当用户显式的把主键定义到了二级索引中时，还需要额外的主键来做二级索引的数据吗(即存储2份主键)? 很显然是不需要的。InnoDB在创建二级索引的时候，会判断主键的字段是否已经被包含在了要创建的索引中.接下来看一下数据操作在B+Tree上的基本实现。- 用主键查询 直接在Clustered B+Tree上查询。- 用辅助索引查询A. 在Secondary B+Tree上查询到主键。B. 用主键在Clustered B+Tree上查询到数据。可以看出，在使用主键值替换页指针后，辅助索引的查询效率降低了。A. 如果能用主键查询，尽量使用主键来查询数据。 B. 但是由于Clustered B+Tree包含了完整的数据，遍历的效率比 Secondary B+Tree的效率低。如果遍历操作不涉及到二级索引和主键以外的数据，则尽量使用二级索引进行遍历。- INSERTA. 在Clustered B+Tree上插入一条记录B. 在所有其他Secondary B+Tree上插入一条记录(仅包含索引字段和主键)- DELETEA. 在Clustered B+Tree上删除一条记录。B. 在所有Secondary B+Tree上删除二级索引的记录。- UPDATE 非键列A. 在Clustered B+Tree上更新数据。- UPDATE 主键列A. 在Clustered B+Tree删除原有的记录(只是标记为DELETED,并不真正删除)。B. 在Clustered B+Tree插入一条新的记录。C. 在每一个Secondary B+Tree上删除原有的记录。(有疑问，看下一节。)D. 在每一个Secondary B+Tree上插入一个条新的记录。- UPDATE 辅助索引的键值A. 在Clustered B+Tree上更新数据。B. 在每一个Secondary B+Tree上删除原有的记录。C. 在每一个Secondary B+Tree上插入一条新的记录。更新键列时，需要更新多个页，效率比较低。A. 尽量不用对主键列进行UPDATE操作。B. 更新很多时，尽量少建索引。05 – 非唯一键索引 教科书上的B+Tree操作，通常都假设”键值是唯一的“。但是在实际的应用中Secondary Index是允许键值重复的。在极端的情况下，所有的键值都一样，该如何来处理呢？InnoDB 的 Secondary B+Tree中，主键也是此二级键的一部分。 Secondary Key = 用户定义的KEY + 主键。注意主键不仅做为数据出现在叶子节点，同时也作为键的一部分出现非叶子节点。对于非唯一键来说，因为主键是唯一的，Secondary Key也是唯一的。当然，在插入数据时，还是会根据用户定义的Key，来判断唯一性。按理说，如果辅助索引是唯一的(并且所有字段不能为空)，就不需要这样做。可是，InnoDB对所有的Secondary B+Tree都这样创建。还没弄明白有什么特殊的用途？有知道的朋友可以帮忙解答一下。也许是为了降低代码的复杂性，这是我想到的唯一理由。弄清楚了,即便是非空唯一键，在二级索引的B+Tree中也可能重复，因此必须要将主键加入到非叶子节点。06 – <Key, Pointer>对 标准的B+Tree的每个节点有K个键值和K+1个指针，指向K+1个子节点。 而在“由浅入深理解索引的实现(1)”中图. 9的B+Tree上，每个节点有K个键值和K个指针。InnoDB的B+Tree也是如此。这样做的好处在于，键值和指针一一对应。我们可以将一个<Key,Pointer>对看作一条记录。这样就可以用数据块的存储格式来存储索引块。因为不需要为索引块定义单独的存储格式，就降低了实现的难度。- 插入最小值 当考虑在变形后的B+Tree上进行INSERT操作时,发现了一个有趣的问题。如果插入的数据的健值比B+Tree的最小键值小时，就无法定位到一个适当的数据块上去(<Key,Pointer>中的Key代表了子节点上的键值是>=Key的)。例如，在图.5的B+Tree中插入键值为0的数据时，无法定位到任何节点。在标准的B+Tree上，这样的键值会被定位到最左侧的节点上去。这个做法，对于图.5中的B+Tree也是合理的。Innodb的做法是，将每一层（叶子层除外）的最左侧节点的第一条记录标记为最小记录(MIN_REC).在进行定位操作时，任何键值都比标记为MIN_REC的键值大。因此0会被插入到最左侧的记录节点上。07 – 顺序插入数据标准的B-Tree分裂时，将一半的键值和数据移动到新的节点上去。原有节点和新节点都保留一半的空间，用于以后的插入操作。当按照键值的顺序插入数据时，左侧的节点不可能再有新的数据插入。因此，会浪费约一半的存储空间。解决这个问题的基本思路是：分裂顺序插入的B-Tree时，将原有的数据都保留在原有的节点上。创建一个新的节点，用来存储新的数据。顺序插入时的分裂过程.以上是以B-Tree为例，B+Tree的分裂过程类似。InnoDB的实现以这个思路为基础，不过要复杂一些。因为顺序插入是有方向性的，可能是从小到大，也可能是从大到小的插入数据。所以要区分不同的情况。如果要了解细节，可参考以下函数的代码。btr_page_split_and_insert();btr_page_get_split_rec_to_right();btr_page_get_split_rec_to_right();InnoDB的代码太复杂了，有时候也不敢肯定自己的理解是对的。因此写了一个小脚本，来打印InnoDB数据文件中B+Tree。这样可以直观的来观察B+Tree的结构，验证自己的理解是否正确。

　　在良好的数据库设计基础上，能有效地使用索引是SQL Server取得高性能的基础，SQL Server采用基于代价的优化模型，它对每一个提交的有关表的查询，决定是否使用索引或用哪一个索引。因为查询执行的大部分开销是磁盘I/O，使用索引提高性能的一个主要目标是避免全表扫描，因为全表扫描需要从磁盘上读表的每一个数据页，如果有索引指向数据值，则查询只需读几次磁盘就可以了。　　所以如果建立了合理的索引，优化器就能利用索引加速数据的查询过程。但是，索引并不总是提高系统的性能，在增、删、改操作中索引的存在会增加一定的工作量，因此，在适当的地方增加适当的索引并从不合理的地方删除次优的索引，将有助于优化那些性能较差的SQL Server应用。实践表明，合理的索引设计是建立在对各种查询的分析和预测上的，只有正确地使索引与程序结合起来,才能产生最佳的优化方案。本文就SQL Server索引的性能问题进行了一些分析和实践。　　一、聚簇索引(clustered indexes)的使用　　聚簇索引是一种对磁盘上实际数据重新组织以按指定的一个或多个列的值排序。由于聚簇索引的索引页面指针指向数据页面，所以使用聚簇索引查找数据几乎总是比使用非聚簇索引快。每张表只能建一个聚簇索引，并且建聚簇索引需要至少相当该表120%的附加空间，以存放该表的副本和索引中间页。建立聚簇索引的思想是：　　1、大多数表都应该有聚簇索引或使用分区来降低对表尾页的竞争，在一个高事务的环境中，对最后一页的封锁严重影响系统的吞吐量。　　2、在聚簇索引下，数据在物理上按顺序排在数据页上，重复值也排在一起，因而在那些包含范围检查(between、<、<=、>、>=)或使用group by或order by的查询时，一旦找到具有范围中第一个键值的行，具有后续索引值的行保证物理上毗连在一起而不必进一步搜索，避免了大范围扫描，可以大大提高查询速度。　　3、在一个频繁发生插入操作的表上建立聚簇索引时，不要建在具有单调上升值的列(如IDENTITY)上，否则会经常引起封锁冲突。　　4、在聚簇索引中不要包含经常修改的列，因为码值修改后，数据行必须移动到新的位置。　　5、选择聚簇索引应基于where子句和连接操作的类型。　　聚簇索引的侯选列是：　　1、主键列,该列在where子句中使用并且插入是随机的。　　2、按范围存取的列，如pri_order > 100 and pri_order < 200。　　3、在group by或order by中使用的列。　　4、不经常修改的列。　　5、在连接操作中使用的列。　　二、非聚簇索引(nonclustered indexes)的使用　　SQL Server缺省情况下建立的索引是非聚簇索引，由于非聚簇索引不重新组织表中的数据，而是对每一行存储索引列值并用一个指针指向数据所在的页面。换句话说非聚簇索引具有在索引结构和数据本身之间的一个额外级。一个表如果没有聚簇索引时,可有250个非聚簇索引。每个非聚簇索引提供访问数据的不同排序顺序。在建立非聚簇索引时，要权衡索引对查询速度的加快与降低修改速度之间的利弊。另外，还要考虑这些问题：　　1、索引需要使用多少空间。　　2、合适的列是否稳定。　　3、索引键是如何选择的，扫描效果是否更佳。　　4、是否有许多重复值。　　对更新频繁的表来说，表上的非聚簇索引比聚簇索引和根本没有索引需要更多的额外开销。对移到新页的每一行而言，指向该数据的每个非聚簇索引的页级行也必须更新，有时可能还需要索引页的分理。从一个页面删除数据的进程也会有类似的开销，另外，删除进程还必须把数据移到页面上部，以保证数据的连续性。所以，建立非聚簇索引要非常慎重。非聚簇索引常被用在以下情况：　　1、某列常用于集合函数(如Sum,....)。　　2、某列常用于join,order by,group by。　　3、查寻出的数据不超过表中数据量的20%。　　三、覆盖索引(covering indexes)的使用　　覆盖索引是指那些索引项中包含查寻所需要的全部信息的非聚簇索引，这种索引之所以比较快也正是因为索引页中包含了查寻所必须的数据,不需去访问数据页。如果非聚簇索引中包含结果数据,那么它的查询速度将快于聚簇索引。　　但是由于覆盖索引的索引项比较多,要占用比较大的空间。而且update操作会引起索引值改变。所以如果潜在的覆盖查询并不常用或不太关键，则覆盖索引的增加反而会降低性能。　　四、索引的选择技术　　p_detail是住房公积金管理系统中记录个人明细的表，有890000行，观察在不同索引下的查询运行效果，测试在C/S环境下进行，客户机是IBM PII350(内存64M),服务器是DEC Alpha1000A(内存128M),数据库为SYBASE11.0.3。　　1、 select count(*) from p_detail where　　op_date>"19990101" and op_date<"　　19991231" and pri_surplus1>300　　2、 select count(*),sum(pri_surplus1) from p_detail　　where op_date>"19990101" and　　pay_month between‘199908" and"199912"　　不建任何索引查询1 1分15秒　　查询2 1分7秒　　在op_date上建非聚簇索引查询1 57秒　　查询2 57秒　　在op_date上建聚簇索引查询1 <1秒　　查询2 52秒　　在pay_month、op_date、pri_surplus1上建索引查询1 34秒　　查询2 <1秒　　在op_date、pay_month、pri_surplus1上建索引查询1 <1秒　　查询2 <1秒　　从以上查询效果分析，索引的有无，建立方式的不同将会导致不同的查询效果，选择什么样的索引基于用户对数据的查询条件,这些条件体现于where从句和join表达式中。一般来说建立索引的思路是：　　(1)主键时常作为where子句的条件，应在表的主键列上建立聚簇索引，尤其当经常用它作为连接的时候。　　(2)有大量重复值且经常有范围查询和排序、分组发生的列，或者非常频繁地被访问的列，可考虑建立聚簇索引。　　(3)经常同时存取多列，且每列都含有重复值可考虑建立复合索引来覆盖一个或一组查询，并把查询引用最频繁的列作为前导列，如果可能尽量使关键查询形成覆盖查询。　　(4)如果知道索引键的所有值都是唯一的，那么确保把索引定义成唯一索引。　　(5)在一个经常做插入操作的表上建索引时，使用fillfactor(填充因子)来减少页分裂，同时提高并发度降低死锁的发生。如果在只读表上建索引，则可以把fillfactor置为100。　　(6)在选择索引键时，设法选择那些采用小数据类型的列作为键以使每个索引页能够容纳尽可能多的索引键和指针，通过这种方式，可使一个查询必须遍历的索引页面降到最小。此外，尽可能地使用整数为键值，因为它能够提供比任何数据类型都快的访问速度。　　五、索引的维护　　上面讲到,某些不合适的索引影响到SQL Server的性能,随着应用系统的运行,数据不断地发生变化,当数据变化达到某一个程度时将会影响到索引的使用。这时需要用户自己来维护索引。索引的维护包括：　　1、重建索引　　随着数据行的插入、删除和数据页的分裂，有些索引页可能只包含几页数据，另外应用在执行大块I/O的时候，重建非聚簇索引可以降低分片，维护大块I/O的效率。重建索引实际上是重新组织B-树空间。在下面情况下需要重建索引：　　(1)数据和使用模式大幅度变化。　　(2)排序的顺序发生改变。　　(3)要进行大量插入操作或已经完成。　　(4)使用大块I/O的查询的磁盘读次数比预料的要多。　　(5)由于大量数据修改，使得数据页和索引页没有充分使用而导致空间的使用超出估算。　　(6)dbcc检查出索引有问题。　　当重建聚簇索引时，这张表的所有非聚簇索引将被重建。　　2、索引统计信息的更新　　当在一个包含数据的表上创建索引的时候，SQL Server会创建分布数据页来存放有关索引的两种统计信息：分布表和密度表。优化器利用这个页来判断该索引对某个特定查询是否有用。但这个统计信息并不动态地重新计算。这意味着，当表的数据改变之后，统计信息有可能是过时的，从而影响优化器追求最有工作的目标。因此，在下面情况下应该运行update statistics命令：　　(1)数据行的插入和删除修改了数据的分布。　　(2)对用truncate table删除数据的表上增加数据行。　　(3)修改索引列的值。　　六、结束语　　实践表明，不恰当的索引不但于事无补，反而会降低系统的执行性能。因为大量的索引在插入、修改和删除操作时比没有索引花费更多的系统时间。例如下面情况下建立的索引是不恰当的：　　1、在查询中很少或从不引用的列不会受益于索引，因为索引很少或从来不必搜索基于这些列的行。　　2、只有两个或三个值的列，如男性和女性(是或否)，从不会从索引中得到好处。　　另外，鉴于索引加快了查询速度，但减慢了数据更新速度的特点。可通过在一个段上建表，而在另一个段上建其非聚簇索引，而这两段分别在单独的物理设备上来改善操作性能。

建立表后ALTERTABLE表名ADDCONSTRAINT[键名]PRIMARYKEYCLUSTERED(字段一ASC,字段二ASC)ON[PRIMARY]或者建表时CREATETABLE表名(字段一INTNOTNULL,字段二[VARCHAR](16)NOTNULLCONSTRAINT[键名]PRIMARYKEYCLUSTERED(字段一ASC,字段二ASC)ON[PRIMARY])ON[PRIMARY]

联机帮助里有很详细的～～～

什么是索引拿汉语字典的目录页（索引）打比方：正如汉语字典中的汉字按页存放一样，SQL Server中的数据记录也是按页存放的，每页容量一般为4K 。为了加快查找的速度，汉语字（词）典一般都有按拼音、笔画、偏旁部首等排序的目录（索引），我们可以选择按拼音或笔画查找方式，快速查找到需要的字（词）。同理，SQL Server允许用户在表中创建索引，指定按某列预先排序，从而大大提高查询速度。u2022 SQL Server中的数据也是按页（ 4KB ）存放u2022 索引：是SQL Server编排数据的内部方法。它为SQL Server提供一种方法来编排查询数据。u2022 索引页：数据库中存储索引的数据页；索引页类似于汉语字（词）典中按拼音或笔画排序的目录页。u2022 索引的作用：通过使用索引，可以大大提高数据库的检索速度，改善数据库性能。索引类型u2022 唯一索引：唯一索引不允许两行具有相同的索引值u2022 主键索引：为表定义一个主键将自动创建主键索引，主键索引是唯一索引的特殊类型。主键索引要求主键中的每个值是唯一的，并且不能为空u2022 聚集索引(Clustered)：表中各行的物理顺序与键值的逻辑（索引）顺序相同，每个表只能有一个u2022 非聚集索引(Non-clustered)：非聚集索引指定表的逻辑顺序。数据存储在一个位置，索引存储在另一个位置，索引中包含指向数据存储位置的指针。可以有多个，小于249个索引类型：再次用汉语字典打比方，希望大家能够明白聚集索引和非聚集索引这两个概念。唯一索引：唯一索引不允许两行具有相同的索引值。如果现有数据中存在重复的键值，则大多数数据库都不允许将新创建的唯一索引与表一起保存。当新数据将使表中的键值重复时，数据库也拒绝接受此数据。例如，如果在stuInfo表中的学员员身份证号(stuID) 列上创建了唯一索引，则所有学员的身份证号不能重复。提示：创建了唯一约束，将自动创建唯一索引。尽管唯一索引有助于找到信息，但为了获得最佳性能，建议使用主键约束或唯一约束。主键索引：在数据库关系图中为表定义一个主键将自动创建主键索引，主键索引是唯一索引的特殊类型。主键索引要求主键中的每个值是唯一的。当在查询中使用主键索引时，它还允许快速访问数据。聚集索引（clustered index）在聚集索引中，表中各行的物理顺序与键值的逻辑（索引）顺序相同。表只能包含一个聚集索引。例如：汉语字（词）典默认按拼音排序编排字典中的每页页码。拼音字母a，b，c，d……x，y，z就是索引的逻辑顺序，而页码1，2，3……就是物理顺序。默认按拼音排序的字典，其索引顺序和逻辑顺序是一致的。即拼音顺序较后的字（词）对应的页码也较大。如拼音“ha”对应的字(词)页码就比拼音“ba” 对应的字(词)页码靠后。非聚集索引(Non-clustered)如果不是聚集索引，表中各行的物理顺序与键值的逻辑顺序不匹配。聚集索引比非聚集索引（nonclustered index）有更快的数据访问速度。例如，按笔画排序的索引就是非聚集索引，“1”画的字（词）对应的页码可能比“3”画的字（词）对应的页码大（靠后）。提示：SQL Server中，一个表只能创建1个聚集索引，多个非聚集索引。设置某列为主键，该列就默认为聚集索引如何创建索引使用T-SQL语句创建索引的语法：CREATE [UNIQUE] [CLUSTERED|NONCLUSTERED] INDEX index_name ON table_name (column_name…) [WITH FILLFACTOR=x]q UNIQUE表示唯一索引，可选q CLUSTERED、NONCLUSTERED表示聚集索引还是非聚集索引，可选q FILLFACTOR表示填充因子，指定一个0到100之间的值，该值指示索引页填满的空间所占的百分比在stuMarks表的writtenExam列创建索引：USE stuDBGOIF EXISTS (SELECT name FROM sysindexes WHERE name = "IX_writtenExam") DROP INDEX stuMarks.IX_writtenExam /*--笔试列创建非聚集索引：填充因子为30％--*/CREATE NONCLUSTERED INDEX IX_writtenExam ON stuMarks(writtenExam) WITH FILLFACTOR= 30GO/*-----指定按索引 IX_writtenExam 查询----*/SELECT * FROM stuMarks (INDEX=IX_writtenExam) WHERE writtenExam BETWEEN 60 AND 90虽然我们可以指定SQL Server按哪个索引进行数据查询，但一般不需要我们人工指定。SQL Server将会根据我们创建的索引，自动优化查询。索引的优缺点u2022 优点– 加快访问速度– 加强行的唯一性u2022 缺点– 带索引的表在数据库中需要更多的存储空间– 操纵数据的命令需要更长的处理时间，因为它们需要对索引进行更新创建索引的指导原则u2022 请按照下列标准选择建立索引的列。– 该列用于频繁搜索– 该列用于对数据进行排序u2022 请不要使用下面的列创建索引：– 列中仅包含几个不同的值。– 表中仅包含几行。为小型表创建索引可能不太划算，因为SQL Server在索引中搜索数据所花的时间比在表中逐行搜索所花的时间更长

CREATE [UNIQUE|CLUSTERED] INDEX INDEX_NAME ON TABLE_NAME(PROPERTY_NAME)其中UNIQUE和CLUSTERED为可选项，分别是建立唯一索引和聚簇索引，具体解释为：UNIQUE:表示此索引的每一个索引值只对应唯一的数据。CLUSTERED:表示要建立的索引时聚簇索引，即索引项的顺序与表中记录的物理顺序一致的索引组织。

CLUSTERED

唯一索引、聚集索引、非聚集索引

clustered index 聚集索引，这类索引是在数据存在一起的。non-clustered 非聚集索引，这类索引是通过找聚集索引来找数据的。两个索引的非叶子节点都是B+或是二叉树之类的，能快速查找的结构。

CREATE INDEX 用户名.索引名 ON 用户名.表名(列名) NOLOGGING NOPARALLEL

创建唯一索引的sql语句如下：CREATE[UNIQUE|CLUSTERED]INDEXINDEX_NAMEONTABLE_NAME(PROPERTY_NAME)其中UNIQUE和CLUSTERED为可选项，分别是建立唯一索引和聚簇索引。具体解释为：UNIQUE：表示此索引的每一个索引值只对应唯一的数据。CLUSTERED：表示要建立的索引时聚簇索引，即索引项的顺序与表中记录的物理顺序一致的索引组织。

指的是聚集索引,索引可分聚集和非聚集索引，这两者区别比较多，但是最主要的区别是：一个表的聚集索引只能有一个，是因为数据行在保存的时候，是按聚集索引的顺序保存的，你可以把它简单的理解成物理存储的位置，这里涉及到页面的概念，你可以查查看。就是物理磁盘上分很多页面，一个有聚集索引的表，他的页面链是按聚集索引排列的，举个例子，如果一个页面已经写满了数据，你要插入一行，如果是非聚集索引，sql会随便找个地方保存，把地址记录进索引，但是如果是聚集索引，会把数据插入到这个页面，而后面的数据同时会往后移动(用页面拆分的办法)，看上去速度要慢，但是聚集索引在搜索时，速度会比非聚集索引快，因为他们是物理排序的

二级索引？？mysql中每个表都有一个聚簇索引（clusteredindex），除此之外的表上的每个非聚簇索引都是二级索引，又叫辅助索引（secondaryindexes）。以innodb来说，每个innodb表具有一个特殊的索引称为聚集索引。如果您的表上定义有主键，该主键索引是聚集索引。如果你不定义为您的表的主键时，mysql取第一个唯一索引（unique）而且只含非空列（notnull）作为主键，innodb使用它作为聚集索引。如果没有这样的列，innodb就自己产生一个这样的id值，它有六个字节，而且是隐藏的，使其作为聚簇索引。聚簇索引主要是为了方便存储。。所以二级索引应该都是对聚簇索引的索引。下面是mysqlmanual上的原话，也可能我理解有误。everyinnodbtablehasaspecialindexcalledtheclusteredindexwherethedatafortherowsisstored.ifyoudefineaprimarykeyonyourtable,theindexoftheprimarykeyistheclusteredindex.ifyoudonotdefineaprimarykeyforyourtable,mysqlpicksthefirstuniqueindexthathasonlynotnullcolumnsastheprimarykeyandinnodbusesitastheclusteredindex.ifthereisnosuchindexinthetable,innodbinternallygeneratesahiddenclusteredindexonasyntheticcolumncontainingrowidvalues.therowsareorderedbytheidthatinnodbassignstotherowsinsuchatable.therowidisa6-bytefieldthatincreasesmonotonicallyasnewrowsareinserted.thus,therowsorderedbytherowidarephysicallyininsertionorder.accessingarowthroughtheclusteredindexisfastbecausetherowdataisonthesamepagewheretheindexsearchleads.ifatableislarge,theclusteredindexarchitectureoftensavesadiski/ooperationwhencomparedtostorageorganizationsthatstorerowdatausingadifferentpagefromtheindexrecord.(forexample,myisamusesonefilefordatarowsandanotherforindexrecords.)ininnodb,therecordsinnon-clusteredindexes(alsocalledsecondaryindexes)containtheprimarykeyvaluefortherow.innodbusesthisprimarykeyvaluetosearchfortherowintheclusteredindex.iftheprimarykeyislong,thesecondaryindexesusemorespace,soitisadvantageoustohaveashortprimarykey.

1 聚集索引：该索引中键值的逻辑顺序决定了表中相应行的物理顺序。 聚集索引确定表中数据的物理顺序。聚集索引类似于电话簿，后者按姓氏排列数据。由于聚集索引规定数据在表中的物理存储顺序，因此一个表只能包含一个聚集索引。但该索引可以包含多个列（组合索引），就像电话簿按姓氏和名字进行组织一样。2 聚集索引使用注意事项 定义聚集索引键时使用的列越少越好。 u2022 包含大量非重复值的列。 .u2022 使用下列运算符返回一个范围值的查询：BETWEEN、>、>=、< 和 <=。 u2022 被连续访问的列。 u2022 回大型结果集的查询。 u2022 经常被使用联接或 GROUP BY 子句的查询访问的列；一般来说，这些是外键列。对 ORDER BY 或 GROUP BY 子句中指定的列进行索引，可以使 SQL Server 不必对数据进行排序，因为这些行已经排序。这样可以提高查询性能。 u2022 OLTP 类型的应用程序，这些程序要求进行非常快速的单行查找（一般通过主键）。应在主键上创建聚集索引。3 聚集索引不适用于： u2022 频繁更改的列 。这将导致整行移动（因为 SQL Server 必须按物理顺序保留行中的数据值）。这一点要特别注意，因为在大数据量事务处理系统中数据是易失的。 u2022 宽键 。来自聚集索引的键值由所有非聚集索引作为查找键使用，因此存储在每个非聚集索引的叶条目内。4 非聚集索引：数据存储在一个地方，索引存储在另一个地方，索引带有指针指向数据的存储位置。非聚集索引中的项目按索引键值的顺序存储，而表中的信息按另一种顺序存储（这可以由聚集索引规定）。对于非聚集索引，可以为在表非聚集索引中查找数据时常用的每个列创建一个非聚集索引。有些书籍包含多个索引。例如，一本介绍园艺的书可能会包含一个植物通俗名称索引，和一个植物学名索引，因为这是读者查找信息的两种最常用的方法。

asc 是降序！（从小到大）

CREATE INDEX 用户名.索引名 ON 用户名.表名(列名) NOLOGGING NOPARALLEL

1. 首先删除主键, 然后重新创建主键, 重新创建主键的时候, 需要说明本主键是使用 非聚集索引PRIMARY KEY NONCLUSTERED ( sno )2.A: PAD_INDEX = { ON | OFF } 指定索引填充。默认值为 OFF。ON fillfactor 指定的可用空间百分比应用于索引的中间级页。OFF 或不指定 fillfactor考虑到中间级页上的键集，将中间级页填充到接近其容量的程度，以留出足够的空间，使之至少能够容纳索引的最大的一行。B:FILLFACTOR =fillfactor指定一个百分比，指示在创建或重新生成索引期间，数据库引擎对各索引页的叶级填充的程度。fillfactor 必须为介于 1 至 100 之间的整数值。默认值为 0。如果 fillfactor 为 100 或 0，则数据库引擎将创建完全填充叶级页的索引。C:IGNORE_DUP_KEY = { ON | OFF } 指定在插入操作尝试向唯一索引插入重复键值时的错误响应。IGNORE_DUP_KEY 选项仅适用于创建或重新生成索引后发生的插入操作。当执行 CREATE INDEX、ALTER INDEX 或 UPDATE 时，该选项无效。默认值为 OFF。ON 向唯一索引插入重复键值时将出现警告消息。只有违反唯一性约束的行才会失败。OFF 向唯一索引插入重复键值时将出现错误消息。整个 INSERT 操作将被回滚。D:STATISTICS_NORECOMPUTE = { ON | OFF} 指定是否重新计算分发统计信息。默认值为 OFF。ON 不会自动重新计算过时的统计信息。OFF 启用统计信息自动更新功能。若要恢复统计信息自动更新，请将 STATISTICS_NORECOMPUTE 设置为 OFF，或执行 UPDATE STATISTICS 但不包含 NORECOMPUTE 子句。E:on [primary] 是指 索引创建在 primary 这个文件组上。3、以全国的身份证为例子：对于 身份证号码， 有个 “唯一” 的索引而对于 姓名， 有个 “不唯一” 的索引。“不唯一” 的索引 ， 虽然不能定位到唯一的某一行， 但是可以缩小范围。定位到某些行。4.聚集索引 CLUSTERED 创建索引时，键值的逻辑顺序决定表中对应行的物理顺序。聚集索引的底层（或称叶级别）包含该表的实际数据行。一个表或视图只允许同时有一个聚集索引。

cpon中填写NULL就行，别不填

在表的索引下面右击 就会看到新建索引选项

你先随便创建一个表，然后加些字段。你直接看 企业管理器里面的的表的原语，就会看到规范的SQL创建数据表的语言，很规范很标准。照它的来，没错的

CREATE INDEX 语句用于在表中创建索引。在不读取整个表的情况下，索引使数据库应用程序可以更快地查找数据。索引您可以在表中创建索引，以便更加快速高效地查询数据。用户无法看到索引，它们只能被用来加速搜索/查询。注释：更新一个包含索引的表需要比更新一个没有索引的表花费更多的时间，这是由于索引本身也需要更新。因此，理想的做法是仅仅在常常被搜索的列（以及表）上面创建索引。实例：在表上创建一个简单的索引。允许使用重复的值：from 树懒学堂-免费数据知识学习平台

主键（sno,cno）为非聚集索引，唯一键（sno）为聚集索引。 clustered 和nonclustered指定为 PRIMARY KEY 或 UNIQUE 约束创建聚集或非聚集索引。PRIMARY KEY 约束默认为 CLUSTERED；UNIQUE 约束默认为 NONCLUSTERED。 聚集索引的区别　　聚集索引:物理存储按照索引排序　　非聚集索引:物理存储不按照索引排序优势与缺点聚集索引：插入数据时速度要慢（时间花费在“物理存储的排序”上，也就是首先要找到位置然后插入）,查询数据比非聚集数据的速度快聚集索引的区别　　聚集索引:物理存储按照索引排序　　非聚集索引:物理存储不按照索引排序优势与缺点聚集索引：插入数据时速度要慢（时间花费在“物理存储的排序”上，也就是首先要找到位置然后插入）,查询数据比非聚集数据的速度快

WITH CHECK | WITH NOCHECK 指定表中的数据是否用新添加的或重新启用的 FOREIGN KEY 或 CHECK 约束进行验证。如果没有指定，对于新约束，假定为 WITH CHECK，对于重新启用的约束，假定为 WITH NOCHECK。还有CLUSTERED 是什么意思?是聚集索引的意思. CLUSTERED | NONCLUSTERED 指定为 PRIMARY KEY 或 UNIQUE 约束创建聚集或非聚集索引。PRIMARY KEY 约束默认为 CLUSTERED；UNIQUE 约束默认为 NONCLUSTERED。 如果表中已存在聚集约束或索引，那么在 ALTER TABLE 中就不能指定 CLUSTERED。如果表中已存在聚集约束或索引，PRIMARY KEY 约束默认为 NONCLUSTERED。这是我从"查询分析器"中的"T-SQL帮助"找的,很有用!

所谓clustered索引,只不过是该索引体现表中数据的实际物理存储顺序,它的叶级索引实际上就是数据本身。正是因为体现了数据的实际存储顺序，所以clustered索引只能有一个，一般情况下，表的主键会是clustered索引。普通索引就可以创建多个了，如果你想通过多个检索条件查询表，就可以分别建立其他普通索引。

1、CREATE [UNIQUE|CLUSTERED] INDEX INDEX_NAME ON TABLE_NAME(PROPERTY_NAME)2、其中UNIQUE和CLUSTERED为可选项，分别是建立唯一索引和聚簇索引，具体解释为：UNIQUE:表示此索引的每一个索引值只对应唯一的数据。3、CLUSTERED:表示要建立的索引时聚簇索引，即索引项的顺序与表中记录的物理顺序一致的索引组织。拓展：1、SQL语言，是结构化查询语言(Structured Query Language)的简称。SQL语言是一种数据库查询和程序设计语言，用于存取数据以及查询、更新和管理关系数据库系统；同时也是数据库脚本文件的扩展名。2、SQL语言是高级的非过程化编程语言，允许用户在高层数据结构上工作。它不要求用户指定对数据的存放方法，也不需要用户了解具体的数据存放方式，所以具有完全不同底层结构的不同数据库系统可以使用相同的结构化查询语言作为数据输入与管理的接口。SQL语言语句可以嵌套，这使他具有极大的灵活性和强大的功能。3、结构化查询语言SQL（STRUCTURED QUERY LANGUAGE）是最重要的关系数据库操作语言，并且它的影响已经超出数据库领域，得到其他领域的重视和采用，如人工智能领域的数据检索，第四代软件开发工具中嵌入SQL的语言等。

1、首先最基本的赋值就是默认值了。2、然后还可以通过数据表查询给变量赋值，如下图所示的数据表。3、可以通过select语句直接给变量赋值。4、赋值以后可以输出一下看看结果。5、然后可以看到结果和数据表的值是一样的。6、最后比较常用的还有set方式赋值。

你这有钻牛角尖了。。query翻译为中文为查询的意思。。如果你真要扣字眼的话。。你要明白查询和查找的区别。。询的意思你可以百度。。是征求意见的意思。。mysql_query的意思也就是执行mysql语句的内容的意思。。唉。。我发现我也蛋疼了。。要是你这样一直死扣字眼是学不好东西。。虽然打破砂锅问到底是好事。。但也要区别看是哪种问题。。

嚼一颗五彩六色的糖豆。

其实一个资源，资源在文件和图片中也存在

WithQuery1dobeginClose;SQL.Clear;SQL.Add(strSQL);//strSQL为SQL语句Open;end;如果你在SQL语句中使用了参数，别忘了给参数赋值。假设有一个参数为UserName.可以这样给它赋值：Query1.ParamByName("UserName").AsString:=StrValue;//StrValue为字符串

先找本书学下吧，比如《深入浅出SQL》中文版

有mysql_query($sql,$linkid)函数，没有query($sql) 函数。

$con = mysql_connect("localhost","mysql_user","mysql_pwd");//连接mysql数据库localhost，以mysql_user用户名和mysql_pwd密码进行连接，得到mysql连接$conif (!$con){//如果连接失败 die("Could not connect: " . mysql_error());//输出错误信息并退出脚本}$sql = "SELECT * FROM Person";//定义查询sql语句:查询Person的所有字段mysql_query($sql,$con);//执行sql语句并返回结果集，结果并没有进行任何处理，对于此次sql查询来说无任何意义，查完了就完了，没有将结果进行任何处理输出等// 一些代码mysql_close($con);//关闭mysql链接

->相当于asp.net中的点，->后因是方法名。调用方法用的

执行sql语句啊。比如：在php里，有这样一句$sql="select * from users"; mysql_query($sql)的作用就是执行$sql这条查询。

query()函数在SQL Server 2008数据库中用于向数据库发出查询请求，以获取数据库中满足特定条件的数据。它可以用于查询单表中的数据，也可以用于查询多个表中的数据。