Category Archives: MySQL

mysql格式化日期

mysql查询记录如果有时间戳字段时，查看结果不方便，不能即时看到时间戳代表的含义，现提供mysql格式换时间函数，可以方便的看到格式化后的时间。 1. DATE_FORMAT() 函数用于以不同的格式显示日期/时间数据。

format参数的格式有   %a 缩写星期名 %b 缩写月名 %c 月，数值 %D 带有英文前缀的月中的天 %d 月的天，数值(00-31) %e 月的天，数值(0-31) %f 微秒 %H 小时 (00-23) %h 小时 (01-12) %I 小时 (01-12) %i 分钟，数值(00-59) %j 年的天 (001-366) %k 小时 (0-23) %l 小时 (1-12) %M 月名 %m 月，数值(00-12) %p AM 或 PM %r 时间，12-小时（hh:mm:ss AM 或 PM） %S 秒(00-59) %s 秒(00-59) %T 时间, 24-小时 (hh:mm:ss) %U 周 (00-53) 星期日是一周的第一天 %u 周 (00-53) 星期一是一周的第一天 %V 周 (01-53) 星期日是一周的第一天，与 %X 使用 %v 周 (01-53) 星期一是一周的第一天，与 %x 使用 %W 星期名 %w 周的天 （0=星期日, 6=星期六） […]

mysql随机获取一条或者多条数据

原文地址：http://www.im286.com/thread-7091552-1-1.html 转来备份 研究一些随机的因素，主要是讲究效率问题。 语句一：

MYSQL手册里面针对RAND()的提示大概意思就是，在 ORDER BY从句里面不能使用RAND()函数，因为这样会导致数据列被多次扫描，导致效率相当相当的低，效率不行，切忌使用。 －－－－－－－－－分隔线－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－ 语句二：

执 行该sql语句，用时0.031s，效率非常好。当把”LIMIT 1“改为了”LIMIT 100“ 随机取一百条记录，用时0.048s。可是就在此时问题出现了，发现结果好像不是随机的。为了验证结果，又执行了N次，的确不是随机的。问题出现 在”ORDER BY t1.userId“这里，按userId排序了。随机取一条记录还是不错的选择，多条就不行了啊。 －－－－－－－－－分隔线－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－ 语句三：

执行该sql语句，用时0.039s，效率也是非常好。接着把”LIMIT 1“改为了”LIMIT 10000“，用时0.063s。经过多次验证，得出的结果都是随机的。 －－－－－－－－－分隔线－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－ 结论：语句一效率不行，切忌使用。随机获得一条记录，语句二是相当不错的选择，采用JOIN的语法比直接在WHERE中使用函数效率还是要高一些的。语句三也不错，随机获得多条记录的首选。   from:http://www.cnblogs.com/leezhxing/p/3951801.html

数据库中间件 MyCAT

MyCAT 是一个彻底开源的，面向企业应用开发的“大数据库集群” 支持事务、ACID、可以替代Mysql的加强版数据库 ? 一个可以视为“Mysql”集群的企业级数据库，用来替代昂贵的Oracle集群 ? 一个融合内存缓存技术、Nosql技术、HDFS大数据的新型SQL Server ? 结合传统数据库和新型分布式数据仓库的新一代企业级数据库产品 ? 一个新颖的数据库中间件产品。 目标 低成本的将现有的单机数据库和应用平滑迁移到“云”端，解决数据存储和业务规模迅速增长情况下的数据瓶颈问题。 关键特性 支持 SQL 92标准 支持Mysql集群，可以作为Proxy使用 支持JDBC连接ORACLE、DB2、SQL Server，将其模拟为MySQL Server使用 支持galera for mysql集群，percona-cluster或者mariadb cluster，提供高可用性数据分片集群，自动故障切换，高可用性 ，支持读写分离，支持Mysql双主多从，以及一主多从的模式 ，支持全局表，数据自动分片到多个节点，用于高效表关联查询 ，支持独有的基于E-R 关系的分片策略，实现了高效的表关联查询多平台支持，部署和实施简单。 优势 基于阿里开源的Cobar产品而研发，Cobar的稳定性、可靠性、优秀的架构和性能，以及众多成熟的使用案例使得MyCAT一开始就拥有一个很好的起点，站在巨人的肩膀上，我们能看到更远。广泛吸取业界优秀的开源项目和创新思路，将其融入到MyCAT的基因中，使得MyCAT在很多方面都领先于目前其他一些同类的开源项目，甚至超越某些商业产品。MyCAT背后有一只强大的技术团队，其参与者都是5年以上资深软件工程师、架构师、DBA等，优秀的技术团队保证了MyCAT的产品质量。 MyCAT并不依托于任何一个商业公司，因此不像某些开源项目，将一些重要的特性封闭在其商业产品中，使得开源项目成了一个摆设。 MyCat架构 长期规划 在支持Mysql的基础上，后端增加更多的开源数据库和商业数据库的支持，包括原生支持PosteSQL、FireBird等开源数据库，以及通过JDBC等方式间接支持其他非开源的数据库如Oracle、DB2、SQL Server等实现更为智能的自我调节特性，如自动统计分析SQL，自动创建和调整索引，根据数据表的读写频率，自动优化缓存和备份策略等实现更全面的监控管理功能与HDFS集成，提供SQL命令，将数据库装入HDFS中并能够快速分析集成优秀的开源报表工具，使之具备一定的数据分析的能力。   from:https://www.oschina.net/p/mycat

我的my.ini

innodb_file_per_table

MySQL InnoDB引擎 默认会将所有的数据库InnoDB引擎的表数据存储在一个共享空间中：ibdata1，当增删数据库的时候，ibdata1文件不会自动收缩，单个数据库的备份也将成为问题。通常只能将数据使用mysqldump 导出，然后再导入解决这个问题。 在MySQL的配置文件[mysqld]部分，增加innodb_file_per_table参数，可以修改InnoDB为独立表空间模式，每个数据库的每个表都会生成一个数据空间。   注意： 如果启用了innodb_file_per_talbe参数，需要注意的是每张表的表空间内存放的只是数据、索引和插入缓冲Bitmap页，其他数据如：回滚信息、插入缓冲索引页、系统事物信息、二次写缓冲（Double write buffer）等还是放在原来的共享表空间内。同时说明了一个问题：即使启用了innodb_file_per_table参数共享表空间还是会不断的增加其大小的。 独立表空间优缺点： 优点： 1：每个表的数据、索引存放在自己单独的表空间中。 2：空间可以回收（drop/truncate table 方式操作表空间不能自动回收） 3：对于独立的表空间、碎片影响的性能要低于共享表空间 缺点： 单表增加比共享表空间方式更大 结论： 共享表空间在Insert操作上有一些优势，但在其它都没独立表空间表现好。 当启用独立表空间时，请合理调整一下 innodb_open_files 参数。 from:http://www.cnblogs.com/xiaoit/p/4096165.html

Mysql高并发优化

一、数据库结构的设计 1、数据行的长度不要超过8020字节，如果超过这个长度的话在物理页中这条数据会占用两行从而造成存储碎片，降低查询效率。 2、能够用数字类型的字段尽量选择数字类型而不用字符串类型的（电话号码），这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接会逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。 3、对于不可变字符类型char和可变字符类型varchar 都是8000字节,char查询快，但是耗存储空间，varchar查询相对慢一些但是节省存储空间。在设计字段的时候可以灵活选择，例如用户名、密码等长度变化不大的字段可以选择CHAR，对于评论等长度变化大的字段可以选择VARCHAR。 4、字段的长度在最大限度的满足可能的需要的前提下，应该尽可能的设得短一些，这样可以提高查询的效率，而且在建立索引的时候也可以减少资源的消耗。 二、查询的优化 保证在实现功能的基础上，尽量减少对数据库的访问次数(可以用缓存保存查询结果，减少查询次数)；通过搜索参数，尽量减少对表的访问行数,最小化结果集，从而减轻网络负担；能够分开的操作尽量分开处理，提高每次的响应速度；在数据窗口使用SQL时，尽量把使用的索引放在选择的首列；算法的结构尽量简单；在查询时，不要过多地使用通配符如SELECT * FROM T1语句，要用到几列就选择几列如：SELECTCOL1,COL2 FROM T1；在可能的情况下尽量限制尽量结果集行数如：SELECT TOP 300 COL1,COL2,COL3 FROM T1,因为某些情况下用户是不需要那么多的数据的。 在没有建索引的情况下，数据库查找某一条数据，就必须进行全表扫描了，对所有数据进行一次遍历，查找出符合条件的记录。在数据量比较小的情况下，也许看不出明显的差别，但是当数据量大的情况下，这种情况就是极为糟糕的了。 1.应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如： select id from t where num is null 可以在num上设置默认值0，确保表中num列没有null值，然后这样查询： select id from t where num=0 2.应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。优化器将无法通过索引来确定将要命中的行数,因此需要搜索该表的所有行。 3.应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如： select id from t where num=10 or num=20 可以这样查询： select id from t where num=10 union all select id from t where num=20 4.in 和 not in 也要慎用，因为IN会使系统无法使用索引,而只能直接搜索表中的数据。如： select id from t where num in(1,2,3) 对于连续的数值，能用 between 就不要用 in 了： select […]

mysql高并发性能的关键要素

前言：最近一直在做项目的性能优化，经历了一个多星期的弯路，终于找到了一个突破点，经过和同事（非常感谢，稍后他会将过程写在他的博客，我会把连接地址跟贴到本博客）的努力，我们的期货交易平台性能在服务端已经得到很好的提升。 首先我们先看一下，我的电脑（i3-3220，4G内存，没有配置innodb_buffer_pool_size参数的情况下，抛开程序的性能，经过1个线程-8个线程的测试结果）环境下，大家可以看到如下的图，线程并发情况下，时间不断的攀升，这让人好苦恼，说好的高性能，高并发呢？ 结果： 不过经过一个多星期的努力，不经意间，我在同事的电脑上发现，同样的代码测试后，时间和我的不是一个等量级的，要比我的电脑快很多，他的电脑（其他条件等同，CPU为i3-4150），8个商品8000挂单下能达到135ms，首先说明CPU的提升对程序处理来说是非常有效果的，但是依然在高并发的情况下，表现的很差劲。 时至今日，通过比对mysql的配置文件my.ini，不经意间，我们发现innodb_buffer_pool_size在8M和48M的配置下，性能简直就不在一个等级上，OK，那就继续调查吧，最终得出如下结论   ? 1 2 innodb_buffer_pool_size=2G innodb_buffer_pool_instances=1 详细的解释，可以看如下介绍 ? 1 2 3 4 5 6 7 8 # InnoDB, unlike MyISAM, uses a buffer pool to cache both indexes and # row data. The bigger you set this the less disk I/O is needed to # access data in tables. On a dedicated database server you may set this # parameter up to 80% of the machine physical memory size. Do not set it # too large, though, because competition of the physical memory […]

Mysql做到高并发几点注意事项

1、拆分大的DELETE或INSERT语句   如果你需要在一个在线的网站上去执行一个大的DELETE或INSERT查询，你需要非常小心，要避免你的操作让你的整个网站停止相应。因为这两个操作是会锁表的，表一锁住了，别的操作都进不来了。 如果你把你的表锁上一段时间，比如30秒钟，那么对于一个有很高访问量的站点来说，这30秒所积累的访问进程/线程，数据库链接，打开的文件数，可能不仅仅会让你泊WEB服务Crash，还可能会让你的整台服务器马上掛了。 所以，如果你有一个大的处理，你定你一定把其拆分，使用LIMIT条件是一个好的方法。下面是一个示例 2、垂直分割 “垂直分割”是一种把数据库中的表按列变成几张表的方法，这样可以降低表的复杂度和字段的数目，从而达到优化的目的。（以前，在银行做过项目，见过一张表有100多个字段，很恐怖） 示例一：在Users表中有一个字段是家庭地址，这个字段是可选字段，相比起，而且你在数据库操作的时候除了个人信息外，你并不需要经常读取或是改写这个字段。那么，为什么不把他放到另外一张表中呢？这样会让你的表有更好的性能，大家想想是不是，大量的时候，我对于用户表来说，只有用户ID，用户名，口令，用户角色等会被经常使用。小一点的表总是会有好的性能。 示例二：你有一个叫“last_login”的字段，它会在每次用户登录时被更新。但是，每次更新时会导致该表的查询缓存被清空。所以，你可以把这个字段放到另一个表中，这样就不会影响你对用户ID，用户名，用户角色的不停地读取了，因为查询缓存会帮你增加很多性能。hp程序员之家 另外，你需要注意的是，这些被分出去的字段所形成的表，你不会经常性地去Join他们，不然的话，这样的性能会比不分割时还要差，而且，会是极数级的下降   3、选择正确的存储引擎 在MySQL中有两个存储引擎MyISAM和InnoDB，每个引擎都有利有弊。酷壳以前文章《mysql: InnoDB 还是 MyISAM?》讨论和这个事情。hp程序员之家 MyISAM适合于一些需要大量查询的应用，但其对于有大量写操作并不是很好。甚至你只是需要update一个字段，整个表都会被锁起来，而别的进程，就算是读进程都无法操作直到读操作完成。另外，MyISAM对于 SELECT COUNT(*) 这类的计算是超快无比的。 www~phperz~com InnoDB的趋势会是一个非常复杂的存储引擎，对于一些小的应用，它会比 MyISAM还慢。他是它支持“行锁” ，于是在写操作比较多的时候，会更优秀。并且，他还支持更多的高级应用，比如：事务。   Myisam读的效果好，写的效率差，这和它数据存储格式，索引的指针和锁的策略有关的。 数据存储格式：Myisam的数据是顺序存储的，innodb数据存储方式是聚簇索引。 索引的指针：Myisam的索引btree上的节点是一个指向数据物理位置的指针，所以查找起来很快，innodb索引节点存的则是数据的主键，所以需要根据主键二次查找。 锁的策略：Myisam锁是表锁，只有读读之间是并发的，写写之间和读写之间（读和插入之间是可以并发的，去设置concurrent_insert参数，定期执行表优化操作，更新操作就没有办法了）是串行的，所以写起来慢，并且默认的写优先级比读优先级高，高到写操作来了后，可以马上插入到读操作前面去，如果批量写，会导致读请求饿死，所以要设置读写优先级或设置多少写操作后执行读操作的策略;Myisam不要使用查询时间太长的sql，如果策略使用不当，也会导致写饿死，所以尽量去拆分查询效率低的sql。 Innodb一般都是行锁，这个一般指的是sql用到索引的时候，行锁是加在索引上的，不是加在数据记录上的，如果sql没有用到索引，仍然会锁定表。mysql的读写之间是可以并发的，普通的select是不需要锁的，当查询的记录遇到锁时，用的是一致性的非锁定快照读，也就是根据数据库隔离级别策略，会去读被锁定行的快照，其它更新或加锁读语句用的是当前读，读取原始行；因为普通读与写不冲突，所以innodb不会出现读写饿死的情况，又因为在使用索引的时候用的是行锁，锁的粒度小，竞争相同锁的情况就少，就增加了并发处理，所以并发读写的效率还是很优秀的，问题在于索引查询后的根据主键的二次查找导致效率低； 注意： Innodb 聚集索引是按照主键（primarykey）进行聚集,被索引的列其实是主键列,如果没定义主键,Innodb会试着使用唯一非空索引Unique Index来代替。其他索引(普通索引)中不会保存行的物理位置,而是保存主键的值,所以通过"二级索引"进行查找是先找到主键,再找到行,要进行二次索引查找 组合索引和单列索引 组合索引在多列上创建，单列索引在一个列上创建。 查询使用索引的条件不同一般组合索引需要按照“最左前缀”来执行查询，并不是每个列都需要覆盖，只是从左边的列开始组合。 原因： 多列索引是先按照第一列进行排序，然后在第一列排好序的基础上再对第二列排序，如果没有第一列的话，直接访问第二列，那第二列肯定是无序的，直接访问后面的列就用不到索引了。索引的最大好处就是：它必然是有序的。如果这个优点都不能利用，那索引也就没什么价值了。 例如有索引key(a,b,c) ³where a=xx and b=xx and c=xxx 此语句可以用到索引 ³where b=xx and a=xx and c=xxx 同上，顺序没有关系，同样能用到索引 ³where a=xx and b=xx 可以用到索引 ³where a=xx and c=xx 可以用到索引（这个以前一直理解错了） ³where b=xx and c=xx 用不到索引 ³where b=xx 用不到索引 ³where c=xx 用不到索引 from:http://blog.csdn.net/u011191420/article/details/53337802

Timeout expired 超时时间已到. 达到了最大池大小 错误及Max Pool Size设置

参考数据库链接串： <add key="data" value="server=192.168.1.123; Port=3306; uid=root; pwd=root;database=data;pooling=true;min pool size=5;max pool size=512;connect timeout = 20; "/>   查看应用程序池占用数量： select * from sysprocesses where dbid= db_id('数据库名')     Max Pool Size：如果未设置则默认为100，理论最大值为32767。最大连接数是连接池能申请的最大连接数，如果数据库连接请求超过此数，后面的数据库连接请求将被加入到等待队列中，这会影响之后的数据库操作。在等待队列中，默认等待与服务器的连接的时间为15秒。   中文错误： 超时时间已到。超时时间已到，但是尚未从池中获取连接。出现这种情况可能是因为所有池连接均在使用，并且达到了最大池大小。 英文错误： Timeout expired.  The timeout period elapsed prior to obtaining a connection from the pool.  This may have occurred because all pooled connections were in use and max pool size was reached. 问题描述：我们获取连接超过连接池最大值时产生如上异常。通常连接池最大值为100。当我们获取连接超过最大值时，ADO.NET等待连接池返回连接而超时，这样将抛出如上异常 解决办法：首先要做的是在我们使用连接后立即关闭连接。如果没有关闭连接那么连接将保存到连接池中知道GC来销毁。这种情况下你以为连接池没有到达最大值但实际上连接池已经到达了最大值 其次我们可以通过连接字符串中的Max Pool Size = N;来动态扩大连接池中的连接最大数量。 说明： 也就是在connectionString中如果未指定max pool size的值，则max pool size=100，当访问人员同时连接数据库的数量为101人时，则等待SqlConnection.ConnectionTimeout设置的时间（默认是15 秒）后，还是没有可用的Connection则会出现上面的错误。 当我们设置为： "Server=(local); Integrated Security=SSPI; Database=Northwind; Max Pool Size=512; Min Pool Size=5"  时。则访问人员同时连接数据库的数量为513时，则等待SqlConnection.ConnectionTimeout设置的时间（默认是15 秒）后，还是没有可用的Connection则 就会出现上面的错误。     –          Connection Pool 是什么呢 ? 每当程序需要读写数据库的时候。Connection.Open()会使用ConnectionString连接到数据库，数据库会为程序建立 一个连接，并且保持打开状态，此后程序就可以使用T-SQL语句来查询/更新数据库。当执行到Connection.Close()后，数据库就会关闭当 前的连接。很好，一切看上去都是如此有条不紊。 但是如果我的程序需要不定时的打开和关闭连接，（比如说 ASP.Net 或是 Web Service […]