mysql发展史
对于MySQL的历史，相信很多人早已耳熟能详，这里就不要赘述。下面仅从产品特性的角度梳理其发展过程中的里程碑事件。1995年，MySQL1.0发布，仅供内部使用。1996年，MySQL3.11.1发布，直接跳过了MySQL2.x版本。1999年，MySQLAB公司成立。同年，发布MySQL3.23，该版本集成了BerkeleyDB存储引擎。该引擎由Sleepycat公司开发，支持事务。在集成该引擎
#每个端口监听队列最大长度net.core.somaxconn=65535#增加系统文件描述符限制fs.file-max=65535#当网络接受速率大于内核处理速率时，允许发送到队列中的包数目net.core.netdev_max_backlog=65535##保持未连接的包最大数量net.ipv4.tcp_max_syn_backlog=65535#控制tcp链接等待时间加快tcp链接回收net
rpm定制
1）readuncommitted:读取尚未提交的数据：哪个问题都不能解决2）readcommitted：读取已经提交的数据：可以解决脏读----oracle默认的3）repeatableread：重读读取：可以解决脏读和不可重复读---mysql默认的4）serializable：串行化：可以解决脏读不可重复读和虚读---相当于锁表
mysql5.7为了安全考虑,初始化后root密码随机生成,密码放在error日志里面.分两步:第一步获取error.log密码.修改默认密码,passwd=`grep 'generated for root@localhost' $base_log/error.log|awk '{print $NF}'`
今天大数据研发同事反馈在抽取数据时一直报错.让开发提供报错日志如下:Incorrect key file for table '/export/data/mysql/tmp/#sql_6c04_4.MYI'; try to repair it at com.mysql.jdb
今天看到一个ppt提到这个mysqlar监控工具，但是网上安装的方法几乎都有问题。因此自己就整理了一份。供大家参考有什么请留言下载软件wget http://oss.oetiker.ch/rrdtool/pub/rrdtool-1.4.8.tar.gz wget http://fossies.org/linux/privat/mysqlard-1.0.0.tar.gz解压tar
wget http://dl.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpmrpm -ivh epel-release-5-4.noarch.rpm安装bzr客户端# yum clean all# yum install bzrDep
如果你没有修改过MySQL的配置，缺省情况下，wait_timeout的初始值是28800。wait_timeout过大有弊端，其体现就是MySQL里大量的SLEEP进程无法及时释放，拖累系统性能，不过也不能把这个指设置的过小，否则你可能会遭遇到“MySQL has gone away”之类的问题，通常来说，我觉得把wait_timeout设置为10是个不错的选择，但某些情况下可能也会出问题，比如
# mysqlslap -uroot -pxxx --debug-info --engine=innodb --concurrency=300,400 --auto-generate-sql-load-type=read,write --create-schema=test query=test.sqlWarning: Using a password on the command line
1.select里面包含的下面的函数，将不被缓存BENCHMARK()CONNECTION_ID()CURDATE() CURRENT_DATE()CURRENT_TIME()CURRENT_TIMESTAMP() CURTIME()DATABASE()带一个参数的ENCRYPT() FOUND_ROWS()GET_LOCK()LAST_INSERT_ID() LOAD_FILE()MASTER_
进行MySQL的配置优化，首先必须找出MySQL的性能瓶颈所在；而SHOW STATUS输出的报告正是用来计算性能瓶颈的参考数据。mysqlreport不像SHOW STATUS那样简单的罗列数据，而是对这些参考数据加以融合计算，整理成一个个优化参考点，然后DBA就可以根据这个优化参考点的值以及该点的衡量标准，进行对应调整。在分析报告中有好多没有完整的说明因此就写了这篇博文。些翻译不对的。请及时和
我们在测试 5.6 GTID 的时候，发现了一个导致主备数据丢失的场景。特别提醒一下使用 MySQL 5.6 并启用了 GTID 的各位，以避免这种情况发生。同时也简单介绍了 GTID 的实现原理。场景描述有一台 MySQL 实例 A ，启用了 GTID 。由于 MySQL 服务器空间吃紧，我们手工将主库的所有的 binlog以及 binlog 的 index 文件都删除掉，并启动了这个 MySQ
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号
