MYSQL教程之分歧操纵平台上mysql的功能对照实行

不可否认，MySQL也是一个很好的关系型数据库，或许在技术上它与其他领先的关系数据库相差并不大，或不具有劣势。但是，对于一些企业环境来说，MySQL显然不具有优势。mysql|功能这个文件中包括了分歧基准测试的了局。

测试了局后（）中的数字暗示准确测试中实行的SQL命令的数量。一个测试能够有良多分歧的参数，这里只给出一个大抵的模样。请检察源码以取得更多的信息。

注重，利用分歧--cmp选项的测试了局不克不及举行对照。--cmp选项依据测试中全体服务器的最差的限定举行设置。

标志了‘+’的数字是依据上一次的运转了局举行估量得出的，由于查询语句的实行超越了给定的工夫限定。这个估量和料想中的实在的了局不会相差很远。

标志了‘？’的数字是一个糟的了局。它只能用来讲明服务器发生这个糟了局所花的工夫：）

但愿这能使你对每种数据库的运转情形有一些熟悉....

第一列是用秒记数的。其他列都是与第一列相干的。1.00暗示不异。更年夜的数字暗示速率更慢。

这是分歧平台上mysql的对照的测试了局。测试情况为：
1mysql-Linux_2.2.1_i686MySQL3.22.18
pentiumpro400mzx2,256M,SCSI,gcc2.9compiled,key_buffer=16M
2mysql_fast-Linux_2.2.1_i686MySQL3.22.18--fast
pentiumpro400mzx2,256M,SCSI,gcc2.9compiled,key_buffer=16M
3mysql-win98MySQL3.22.19a
"AMD-K6350MHz,256Mmemory,key_buffer=16M"
4mysql_odbc-win98MySQL3.22.19a--odbc
5mysql-NT_4.0MySQL3.22.18gamma
"AMD-K6350MHz,256Mmemory,key_buffer=16M"
6mysql-SunOS_5.5.1_sun4uMySQL3.22.19
UltraSPARC,2CPU200MHz,1Gmem,key_buffer=8M
7mysql-SunOS_5.6_sun4mMySQL3.22.6alpha
Sparcsun4m,196Mmemory
8mysql-SunOS_5.7_sun4uMySQL3.22.18
UltraSPARC-II2/CPU400MHz,2Gmem,key_buffer=16M

操纵1
mysql2
mysql_fast3
mysql4
mysql_odbc5
mysql6
mysql7
mysql8
mysql

每项测试的了局（第一列以秒记，前面列为第一列的倍数）：
ATIS660.953.674.472.333.1415.001.58
alter-table8120.992.662.697.081.643.901.31
big-tables491.004.555.083.672.6512.241.53
connect1510.993.6910.783.132.138.861.05
create91.3315.1116.228.788.3361.4425.67
insert15580.93+3.18+3.915.922.33+15.812.23
select+1164+0.98+2.60+2.78+1.77+2.69+13.26+1.56
wisconsin200.504.406.752.702.9512.051.65

每项操纵的了局：
alter_table_add(992)4530.992.562.596.741.716.771.38
alter_table_drop(496)3431.012.792.817.501.56　1.22
connect(10000)311.002.5510.872.612.558.770.97
connect+select(10000)350.973.0614.602.772.499.091.09
count(100)620.981.451.501.582.117.921.06
count_on_key(50100)+719+0.97+2.89+3.03+1.71+3.06+15.66+1.79
create+drop(1000)11.0025.0027.0017.0022.00154.0069.00
create_index(8)90.672.442.446.671.225.331.00
create_key+drop(1000)31.009.0010.008.336.6753.6722.33
create_table(1031)41.5012.2513.007.005.5039.5013.75
delete_big(15)1560.151.331.367.882.1047.741.79
delete_key(500)261.150.040.080.040.040.120.04
drop_index(8)61.173.673.6710.002.008.001.33
drop_table(1028)11.007.009.002.0010.0080.0041.00
insert(350768)1470.315.078.163.642.9610.781.95
insert_duplicates(300000)260.885.7710.773.272.279.151.38
insert_key(100000)1560.823.124.1525.712.7725.679.20
insert_many_fields(2000)131.082.542.854.153.0812.231.38
min_max(60)381.001.291.341.342.269.551.13
min_max_on_key(73000)1980.952.342.571.962.08+10.331.25
multiple_value_inser(100000)91.006.444.442.672.6710.441.56
order_by(10)721.115.396.822.832.99+18.001.49
order_by_key(10)471.265.837.873.232.91+17.171.77
select(20000)71.147.8611.713.572.5711.572.29
select_big(10080)911.115.186.543.551.9612.631.32
select_distinct(800)170.942.943.411.823.1214.591.59
select_group(3811)1050.972.452.571.632.8912.701.37
select_join(200)261.084.505.462.353.4618.191.69
select_key(200000)2120.97+3.99+4.312.482.21+9.261.24
select_key_prefix(200000)2430.97+3.52+3.822.191.93+8.481.16
select_many_fields(2000)351.005.376.003.402.5412.541.60
select_range(25420)3311.011.922.121.712.17+8.881.14
select_range_prefix(25010)371.002.843.111.922.359.351.30
select_simple(20000)361.003.3913.222.752.589.141.11
select_simple_join(500)30.673.674.332.332.6711.671.00
update_key(500)31.330.330.670.330.331.000.67
update_key_big(501)371.081.511.591.192.2210.271.46
update_of_key(256)792.591.371.3916.621.8912.352.43
wisc_benchmark(114)70.863.144.142.142.2913.001.43
总计+3824+0.96+2.98+3.65+4.70+2.33+12.28+1.82对于现有业务，可以轻松移植到MySQL。当你需要替换掉老的硬件，当你需要削减历史遗留下的老系统的时候，选用MySQL对于财务部门来说更具吸引力。

可能有的朋友会抱怨集成的orderby，其实如果使用ranking函数,Orderby是少不了的。如果担心Orderby会影响效率，可以为orderby的字段建立聚集索引，查询计划会忽略orderby操作（因为本来就是排序的嘛）。

多加的系统视图和实时系统信息这些东西对DBA挑优非常有帮助，但是感觉粒度还是不太细。

所以你总能得到相应的升级版本，来满足你的需求。

我是一个ERP初学者，对于前台运用基本熟悉，但对于后台SQLServer的运用一点也不懂，特想学习下相关资料。至少懂得一些基本的运用。希望各位能给于建议，小弟再谢过！

作了些试验，发现使用CLR的存储过程或函数在达到一定的阀值的时候，系统性能会呈指数级下滑！这是非常危险的！只使用几个可能没有问题，当一旦大规模使用会造成严重的系统性能问题！

其中最有名的应该是row_number了。这个终于解决了用临时表生成序列号的历史，而且SQLServer2005的row_number比Oracle的更先进。因为它把Orderby集成到了一起，不用像Oracle那样还要用子查询进行封装。

XML字段类型更好的解决了XML数据的操作。XQuery确实不错，但是个人对其没好感。（CSDN的开发者应该是相当的熟了！）

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