发布怎样修正Linux下MySQL 5.0的默许毗连数
无疑希望员工得到系统、有深度的培训，显然MySQL在这一点上还做得很不够。这段工夫服务器溃散2次，一向没有找到缘故原由，明天看到论坛收回的毛病信息邮件，想起多是MySQL的默许毗连数引发的成绩，一查公然，老天，默许毗连数才100，怎样够呀，在网上找了半资质料，有说修正my.cnf的，有说修正safe_mysqld，试了，前者无用，后者文件找不到：)本来是之前的版本跟如今的版本有所分歧。
言回正传,我以centos4.4上面的mysql5.0.33手工编译版本为例申明：
vi/usr/local/mysql/bin/mysqld_safe
找到safe_mysqld编纂它，找到mysqld启动的那两行，在前面加上参数：
-Omax_connections=1500
详细一点就是上面的地位：
用红字出格申明：
then$NOHUP_NICENESS$ledir/$MYSQLD
$defaults--basedir=$MY_BASEDIR_VERSION
--datadir=$DATADIR$USER_OPTION
--pid-file=$pid_file
--skip-external-locking
-Omax_connections=1500
>>$err_log2>&1else
eval"$NOHUP_NICENESS$ledir/$MYSQLD
$defaults--basedir=$MY_BASEDIR_VERSION
--datadir=$DATADIR$USER_OPTION
--pid-file=$pid_file
--skip-external-locking$args
-Omax_connections=1500>>
$err_log2>&1"
保留。
#servicemysqldrestart
#/usr/local/mysql/bin/mysqladmin-uroot-pvariables
输出root数据库账号的暗码后可看到
max_connections1500即新修改已失效。
另有一种办法:
修正原代码:
解开MySQL的原代码，进进内里的sql目次修正mysqld.cc找到上面一行：
{"max_connections",OPT_MAX_CONNECTIONS,
"Thenumberofsimultaneousclientsallowed.",(gptr*)&max_connections,
(gptr*)&max_connections,0,GET_ULONG,REQUIRED_ARG,100,1,16384,0,1,
0},
把它改成：
{"max_connections",OPT_MAX_CONNECTIONS,
"Thenumberofsimultaneousclientsallowed.",(gptr*)&max_connections,
(gptr*)&max_connections,0,GET_ULONG,REQUIRED_ARG,1500,1,16384,0,1,
0},
存盘加入，然后./configure;make;makeinstall能够取得一样的效果。
RDBMS并非没有局限性。它们难以扩展，需要大量的资源来配置和维护，比如时间、硬件和人力。同样，它们往往遵循峰值性能模型，这就要求系统按照峰值容量来配置可用性，而不考虑典型的数据使用情况。 但是随着数据量的增大，这种成本差距会逐渐减小，趋于相等。（500万数量级只相差10%左右） 只能告诉你，学好数据库语言和原理，多见识几种数据库软件，比一棵树上吊死要好。 备份方面可能还是一个老大难的问题。不能单独备份几个表总是感觉不爽。灵活备份的问题不知道什么时候才能解决。 SQL语言是学习所有数据库产品的基础，无论你是做数据库管理还是做数据库开发都是这样。不过具体学习的侧重点要看你将来做哪一块，如果是做数据库管理（DBA），侧重点应该放在SQLServer的系统管理上. 不好!如果出了错;不好调试;不好处理!其实web开发将代码分为3层:web层;业务逻辑层和数据访问层;一般对数据库的操作都在数据访问层来做;这样便于调试和维护!而且将来如果是换了数据库的话;你只需要改数据层的代码;其他层的基本可以不变!要是你在jsp中直接调用sql数据库;那么如果换了数据库呢?岂不都要改?如果报了异常呢?怎么做异常处理? 外键的级联更能扩展可能大部分的同行在设计OLTP系统的时候都不愿意建立外键，都是通过程序来控制父子数据的完整性。 如果是将来做数据库的开发设计，就应该详细学习T-SQL的各种细节，包括T-SQL的程序设计、存储过程、触发器以及具体使用某个开发语言来访问数据库。 数据库物理框架没有变动undo和redo都放在数据库得transaction中，个人感觉是个败笔。如果说我们在设计数据库的时候考虑分多个数据库，可能能在一定程度上避免I/O效率问题。
页:
[1]