MYSQL网站制作之疾速天生100万不反复的8位编号

MySQL对硬件的较低要求是其最大的优势之一，不过需要注意的是：内存越多越好，因为所有的重要数据存储都在内存中完成。反复比来在论坛看到有人问，怎样疾速天生100万不反复的8位编号，关于这个成绩，有几点是必要注重的：
1．怎样天生8位随机数，天生的数越随机，反复的大概性固然越小
2．把持不反复
3．思索功能
针对这个成绩，我写了以下的示例来办理，但愿能为有这类需求的人供应引导

天生100万条8位不反复数据的示例
USEtempdb
GO

--创立测试表
CREATETABLEtb(idchar(8))

--创立用于主动过滤反复值的独一索引
CREATEUNIQUEINDEXIX_tbONtb(id)
WITHIGNORE_DUP_KEY
GO

--测试数据拔出的处置工夫,纪录入手下手处置的工夫点
DECLARE@dtdatetime
SET@dt=GETDATE()

--拔出随机数据
SETNOCOUNTON
DECLARE@rowint
SET@row=1000000--设置总纪录数
WHILE@row>0
BEGIN
--显现提醒信息,暗示还必要拔出多行数据
RAISERROR(need%drows,10,1,@row)WITHNOWAIT

--拔出随机的位编码数据
SETROWCOUNT@row
INSERTtbSELECT
id=RIGHT(100000000+CONVERT(bigint,ABS(CHECKSUM(NEWID()))),8)
FROMsyscolumnsc1,syscolumnsc2
SET@row=@row-@@ROWCOUNT
END

--显现拔出数据利用的工夫
SELECTBeginDate=@dt,EndDate=GETDATE(),
Second=DATEDIFF(Second,@dt,GETDATE()),
GO

--显现终极的了局纪录是不是准确
SELECTCOUNT(*)FROMtb
GO

--删除测试
DROPTABLEtb

办理顶用到的技能：
1．把持发生的数据不反复，间接利用独一索引中的IGNORE_DUP_KEY选项，使拔出数据中的反复值主动过滤，制止手工处置反复
2．利用CHECKSUM共同NEWID()函数，使天生的数据只管随机，一样平常天生随机数会思索利用RAND()函数，但这个函数是发生伪随机值，用上面的语句测试一下，会发明发生的数据全体是一样的，这不合用于想批量天生多个随机数，而NEWID()函数天生的是GUID，基础上不会有反复的，再经由过程CHECKSUM将其转化成数字，如许发生反复的大概性会对照小
SELECTTOP10
RAND()
FROMsysobjects
3．在效力把持，利用轮回+批量天生的体例，而不是传统的逐一天生。在SQLServer中，每一个拔出语句城市有一个外部的事件处置，假如逐条拔出，则事件的开支太年夜，效力必将十分低；不思索一次性天生100万数据，一则由于天生的数据大概有反复的，往失落反复就没有100万了，二则一次性天生100万数据，损耗的内存和CPU资本也很高，一样平常的电脑大概接受不住


你可以配置MySQL运行在微小的嵌入式应用程序中，处理的数据可能不足1Mb??而你也可以用它来处理数Tb的数据。MySQL获得这种可扩展性的路径之一是通过一个人们所熟知的存储过程，这是一个运行在程序之外的微型、预编译程序。

如果，某一版本可以提供强大的并发响应，但是没有Oracle的相应版本稳定，或者价格较贵，那么，它就是不适合的。

也可谈一下你是怎么优化存储过程的?

比如，MicrosoftSQLServer2008的某一个版本可以满足现在的这个业务的需要，而且价格还比Oracle11g要便宜，那么这一产品就是适合的。

现在是在考虑:如果写到服务器端,我一下搞他个10个存储过程导过去,那久之服务器不就成垃圾箱了吗?即便优化了我的中间层.

无法深入到数据库系统层面去了解和探究

这是一个不错的新特性。虽然索引的附加字段没有索引键值效率高，但是相对映射到数据表中效率还是提高了很多。我做过试验，在我的实验环境中会比映射到表中提高30%左右的效率。

我是新手，正在学习数据库和操作系统，深感理论的泛广，唯有一步一步来，但是又感觉时间不够，收集了很多资料却总是没能认真的看完，希望有一个讨论板块，大家共同解决，共同分享，共同努力

如安全管理、备份恢复、性能监控和调优等，SQL只要熟悉基本操作就可以，只要程序设计部分只要稍加了解即可（如存储过程、触发器等）。

微软对CLR作了大篇幅的宣传，这是因为数据库产品终于融入.net体系中。最开始我们也是狂喜，感觉对象数据库的一些概念可以实现了。

数据库物理框架没有变动undo和redo都放在数据库得transaction中，个人感觉是个败笔。如果说我们在设计数据库的时候考虑分多个数据库，可能能在一定程度上避免I/O效率问题。

也可谈一下你是怎么优化存储过程的?