PHP入门

SQL Server事务日志可能会被填满，这会阻止之后的数据库操作，包括UPDATE， DELETE， INSERT 和CHECKPOINT。
事务日志填满会导致1105错误:
Can't allocate space for object syslogs in database dbname because
the logsegment is full。
　If you ran out of space in syslogs， dump
the transaction log。
　Otherwise use ALTER DATABASE or
sp_extendsegment to increase the size of the segment。
这种现象可能出现于任何一个数据库中，包括Master和TempDB。一些难以预见的因素可能消耗日志空间。
　例如:
一个大型事务， 尤其像批量数据更新、插入或删除。
一个未提交的事务。
检查点处理程序截除时所需的带宽过大。
截除时超过阈值
上述各种条件互相作用的结果。
用于发布的标记事务没有被日志读取程序读走

任何基于锁的并发系统的一个不可避免的特点是在某些条件下系统可能阻塞。当一个连接占有一个锁而另一个连接试图改变锁的状态时，第二个连接要么等待第一个连接释放锁，要么因此而被阻塞。
为了获得最好的可扩展性，性能和并发能力，在设计应用程序和查询语句时，应该注意尽量缩短事务的长度， 并且减少占有锁的时间。大多数并发问题往往出现在应用程序和数据库的设计阶段，因此，设计阶段如果充分考虑这个因素至关重要。
　否则，应用程序就会存在潜在的潜能缺陷， 而且一般要到应用程序扩展性测试时才被发现。

在 MySQL 下，在进行中文模糊检索时，经常会返回一些与之不相关的
记录，如查找 "%a%" 时，返回的可能有中文字符，却没有 a 字符存在。
本人以前也曾遇到过类似问题，经详细阅读 MySQL 的 Manual ，发现可以
有一种方法很方便的解决并得到满意的结果。
例子：
·希望通过“标题”对新闻库进行检索，关键字可能包含是中英文，如
下 SQL 语句：
select id,title,name from achech_com.news where title like '%a%'
返回的结果，某些 title 字段确定带了“a”关键字，而有些则只有中文，
但也随之返回在检索结果中。
解决方法，使用 BINARY 属性进行检索，如：
select id,title,name from achech_com.news where binary title like '%a%'
返回的结果较之前正确，但英文字母区分大小写，故有时在检索如“Achech”
及“achech”的结果是不一样的。
知道了使用 BINARY 属性可以解决前面这个问题，再看看 MySQL 支持的
UCASE 及 CONCAT 函数，其中 UCASE 是将英文全部转成大写，而 CONCAT 函
数的作用是对字符进行连接，以下是我们完全解决后的 SQL 语句：
select id,title,name from achech_com.news where binary ucase(title) like concat('%',ucase('a'),'%')
检索的步骤是先将属性指定为 BINARY ，以精确检索结果，而被 like 的 title
内容存在大小写字母的可能，故先使用 ucase 函数将字段内容全部转换成大
写字母，然后再进行 like 操作，而 like 的操作使用模糊方法，使用 concat
的好处是传进来的可以是直接的关键字，不需要带“%”万用符，将“'a'”直接
换成你的变量，在任何语言下都万事无忧了。
当然你也可以这么写：
select id,title,name from achech_com.news where binary ucase(title) like ucase('%a%')
检索的结果还算满意吧，不过速度可能会因此而慢N毫秒喔。
作者：林兴陆·Linxinglu@ihw.com.cn
相关资料：
Relate:
20.16 Case Sensitivity in Searches
By default, MySQL searches are case-insensitive (although there are some character sets that are never case insensitive, such as czech). That means that if you search with col_name LIKE 'a%', you will get all column values that start with A or a. If you want to make this search case-sensitive, use something like INDEX(col_name, "A")=0 to check a prefix. Or use STRCMP(col_name, "A") = 0 if the column value must be exactly "A".

: 我在ms sql中建了一个表,可由于种种原因有些记录重复了
: 记录完全的一模一样。
: 现在我想把重复的都删掉,只保留重复记录中的第一条。
: 我在database好象看到有介绍oracle的，
select distinct * into #table_name from table_name
delete from table_name
select * into table_name from #table_name
drop table #table_name
与此相关的是“select into”选项，可以在数据库属性
对话框中，勾起来此项，或者在Query Analyzer中执行
execute sp_dboption 'db_name','select into','true'
开启。默认值是关闭的。

ACCESS是一个Client/Server的优秀前端开发工具，具有易学易用，界面友好，开发简单，和其他数据库接口灵活。但是，它要对大量数据处理时，速度比较慢。深圳供电局现有60万用户，下面有6个营业所，通过64K DDN 和局相连，如果有一个营业所要对1万用户进行处理的话，要花2~3小时，严重影响其他业务的开展。所以，当有大量数据需要处理时，不能在Client端处理，而必须在Server端处理。
　但ACCESS和Server端之间多数通过ODBC来连接，这样就增加了调用后台存储过程的难度。笔者通过在实际工作中长期的摸索，根据不同的业务需要，可以用下面三种方法去调用后台存储过程。
　　一、 Access 向后台提交作业，这一个个作业对应一个个的存储过程。在SQL Server 6.5中，通过Task Manager 来建立相应的Task; 而在Oracle 8.0中，通过Managing Job Queue 来建立相应的Job。在Access中，在job_list表中插入一个作业，这些作业一般每天晚上运行一次。这些作业对应的业务一般是需要处理非常大量数据，而实时性又是较低的，在我们的业务中比较典型的例子是每天晚上大量的电费计算。
　　二、 在Server端建立一些触发器（Trigger），在Access中激活这些触发器。在SQL Server 6.5 和Oracle 8.0中，都是通过Create Trigger 来实现。在Access中，根据不同的业务，通过插入、修改、删除记录来激活不同触发器。在我们的业务中一个例子是，当业务人员修改用户的电表读数后，激活计算电费的触发器，能立即重新计算该用户的电费。这样子，既可以和批量计算电费共享同一程序，不用在Access端重新开发，有可以加快前端的响应速度。
　　三、 以上二种方法，只可以说是间接调用后台存储过程，Access还提供一种直接调用的方法，可以用Access 传递查询直接将命令发送到数据库服务器。
　　建立Access 传递查询步骤如下：
　　(1) 在数据库窗口中单击“查询”选项卡，然后单击“新建”按钮。
　　(2) 在“新建查询”对话框中单击“设计视图”选项，然后单击“确定”按钮。
　　(3) 在“显示表”对话框内单击“关闭”按钮。
　　(4) 在“查询”菜单上，指到“SQL 语句条件”，然后单击“传递”命令。
　　(5) 在工具栏上，请单击“属性”按钮 以显示查询属性表。
　　(6) 在查询属性表中，请设置“ODBC 连接字符串”属性来指定要连接的数据库信息。可以输入连接信息: ”ODBC;DSN=ntserver0;UID=sa;PWD=;DATABASE=BMS”，或用“生成器”按钮生成。

1. 分号的例外 

　对于 MySQL ，第一件你必须牢记的是它的每一行命令都是用分号 (;) 作为结束的，但……没有完全绝对的事，在这儿也是一样，当一行 MySQL 被插入在 PHP 代码中时，最好把后面的分号省略掉，例如： 

近日，本人为了将为公司开发的一个信息管理系统从以前试运行的开发机器上（Windows NT   IIS4.0   Access)迁移至一台真正的Linux服务器上（Apache1.3.12   PHP 4.03   MySQL 3.23.26），其中数据库中的几十个表的内容迁移，开始让我小费了一些周折，从网上也下载了一些MySqL的客户软件或是数据库管理软件，写得较好的软件均有数据迁移功能，但其迁移方式不外乎两种，一种是采用文件引入方式，此种方式在处理数据库中有和分隔符相同的字符时，会产生错误，尤其是在处理ACCESS中的Memo字段，很容易出错，最后导致导出后的数据不是多了就是少了。而另一种支持ODBC直接导入的功能较强，基本可无错误地导入各个表的内容，但很遗憾，这必须是建立在ACCESS中表格的字段是英文是才可以，如在ACCESS中字段是中文名，一般也出错，不能成功导入。

mysql数据库表sqltable 

字段id，name，sex，email 

在SQL数据库中得到重复次数最多的记录

使用distinct 可以使我们得到一个不重复的记录集

比如查找用户名包含有"c"的所有用户, 可以用

下面是完成上面功能的另一种写法:

举个例子，设表名为bbs 回复数的字段为renum 变量名$renum 记录序号字段为id 变量名$id
当我们在论坛回贴时会要改写主贴的回复数，传统的方法要用到到两句SQL语句：
//取出原值
$query1="select renum bbs where id = '$id'";
……
$renum  ;
//写回数据库

懒得翻译了，大意：
在有合适的索引的时候，Top n和set rowcount n是一样快的。但是对于一个无序堆来说，top n更快。
原理自己看英文去。
Q. Is using the TOP N clause faster than using SET ROWCOUNT N to return a specific number of rows from a query?
A. With proper indexes, the TOP N clause and SET ROWCOUNT N statement are equally fast, but with unsorted input from a heap, TOP N is faster. With unsorted input, the TOP N operator uses a small internal sorted temporary table in which it replaces only the last row. If the input is nearly sorted, the TOP N engine must delete or insert the last row only a few times. Nearly sorted means you're dealing with a heap with ordered inserts for the initial population and without many updates, deletes, forwarding pointers, and so on afterward.
A nearly sorted heap is more efficient to sort than sorting a huge table. In a test that used TOP N to sort a table with the same number of rows but with unordered inserts, TOP N was not as efficient anymore. Usually, the I/O time is the same both with an index and without; however, without an index SQL Server must do a complete table scan. Processor time and elapsed time show the efficiency of the nearly sorted heap. The I/O time is the same because SQL Server must read all the rows either way.