DataBase

PostgreSQL commands \l 或 \list meta-command 列出所有数据库 sudo -u postgres psql -c "\l" 用 \c + 数据库名 来进入数据库： \dt 列出所有数据库表： # 查看表结构, 索引 \d table0 # 比上面多几个字段 Storage | Stats target | Description \d+ table0 # Turn off printing of column names and result row count footers, etc. This is equivalent to \t or \pset tuples_only. \t tuples only on/off, tuples only on 的时候 select 语句的输出不带 header \h \? \du 列出所有的用户 # 创建用户 CREATE USER user_0 WITH PASSWORD 'password_0'; # create database, 所有者 user_0 create database database_0 OWNER user_0; psql -h 192.168.1.100 -p 5432 -U user_0 -d database_0 PGPASSWORD=password_0 psql -h 192.168.1.100 -p 5432 -U user_0 -d database_0 --command 'select version();' #当表没有其他关系时 TRUNCATE TABLE tablename; #当表中有外键时，要用级联方式删所有关联的数据 TRUNCATE TABLE tablename CASCADE; # 查看 表大小 select pg_size_pretty(pg_relation_size('table0')); # 查看配置文件路径, 切换到 postgres 用户执行 psql -c "show config_file" # 查看版本 select version(); pacman -S postgresql psql -h 127.0.0.1 -p 5432 -d database0 -U user0 # create table create table test(id int, c1 int); create table table0(field0 json); # delete table DROP TABLE table0; # 查看字段类型 select column_name, data_type from information_schema.columns where table_name='table0'; select * length( "abc"::TEXT) insert into test select generate_series(1,10000), random()*10; # 复制表结构到另外一个数据库 pg_dump -U postgres --schema-only source_db | psql -U postgres target_db 导入/导出 export, 导出, 备份 # https://www.postgresql.org/download/linux/ubuntu/ # install pg_dump sudo apt install -y postgresql-common # This script will enable the PostgreSQL APT repository on apt.postgresql.org sudo /usr/share/postgresql-common/pgdg/apt.postgresql.org.sh # ubuntu install pg_dump sudo apt-get install postgresql-client-17 # -h, host 127.0.0.1 # -p, port 5432 # -t, table: table0, 不加 -t 参数时会导出所有表结构 # -s, 不导出数据 # database: database0 # -F : 指定输出文件的格式，它可以是以下格式之一： c: 自定义格式 d: 目录格式存档 t: tar 文件包 p: SQL 脚本文件 # -W 命令执行时提示输入用户密码（不会直接在命令中写密码）。 pg_dump -h 127.0.0.1 -U username -W -F t db_name > foo.tar # 导入 # -c --clean 创建数据库对象前先清理（删除）它们。 pg_restore -h 127.0.0.1 -U username -W -d db_name -c foo.tar pg_dump -h 127.0.0.1 -p 5432 -t table_0 -U postgres database0 > foo.sql pg_dump -h 127.0.0.1 -p 5432 -s -t table_0 -U postgres database0 > foo.sql # 导出并压缩 pg_dump -d db_name | gzip > db.gz pg_dump -a -t table_0 "host=127.0.0.1 hostaddr=127.0.0.1 port=5432 user=user_0 password=password_0 dbname=db_0" # export insert sql pg_dump -a -t table_0 "host=127.0.0.1 hostaddr=127.0.0.1 port=5432 user=user_0 password=password_0 dbname=db_0" --inserts 导入 # sql psql -h 127.0.0.1 -p 5432 -t table0 -U postgres -d database0 -f foo.sql # csv, https://stackoverflow.com/questions/26701735/extra-data-after-last-expected-column-while-trying-to-import-a-csv-file-into-p \COPY agency (agency_name, agency_url, agency_timezone) FROM 'myFile.txt' CSV HEADER DELIMITER ','; 导出指定的行 https://stackoverflow.com/questions/12815496/export-specific-rows-from-a-postgresql-table-as-insert-sql-script ...

SQLite version: 3.44.0 SQLite 通过文件来保存数据库，一个文件就是一个数据库 commands # archlinux install sqlite sudo pacman -S sqlite # ubuntu sudo apt install sqlite3 # 打开一个已经存在的数据库 sqlite3 /var/lib/enx-api/enx.db # 启动 sqlite sqlite3 # 列出数据库文件和名字 .databases # query schema, 列出所有的表 .table # 查看表结构, 注意, 表名后面没有分号 .schema table0 # 创建数据库 sqlite3 /data/rssx/rssx.db # insert data insert into table_0 (name) values ('foo'); CREATE TABLE if not exists table_1 (name varchar(50) collate nocase PRIMARY KEY, create_time timestamp DEFAULT NULL); insert into table_1 (name) values ('foo'); insert into table_1 (name) values ('Foo'); -- Runtime error: UNIQUE constraint failed: table_1.name (19) # help .help # show tables .tables # insert # alter table, rename alter table feed rename to feeds; -- query that returns the size of a table in a SQLite database -- 空表的 size 是 4096 select sum("pgsize") from "dbstat" where name='table0'; -- drop table drop table table0; SQLite，是一种轻型的数据库，是遵守 ACID 的关联式数据库管理系统，它的设计目标是嵌入式的，而且目前已经在很多嵌入式产品中使用了它， 它占用资源非常地低，在嵌入式设备中，可能只需要几百K的内存就够了。它能够支持 Windows/Linux/Unix 等等主流的操作系统， 同时能够跟很多程序语言相结合，比如 Tcl、C#、PHP、Java等，还有ODBC接口，同样比起 MySQL、PostgreSQL 这两款开源世界著名的数据库管理系统来讲， 它的处理速度比他们都快。SQLite 第一个Alpha 版本诞生于2000年5月。 至今已经有12个年头，SQLite 也迎来了一个版本 SQLite 3 已经发布。 ...

数据库事务, 锁 数据库锁 因为数据库要解决并发控制问题。在同一时刻，可能会有多个客户端对同一张表进行操作，比如有的在读取该行数据，其他的尝试去删除它。为了保证数据的一致性，数据库就要对这种并发操作进行控制，因此就有了锁的概念。 锁的分类 从对数据库操作的类型分 读锁（共享锁）：针对同一块数据，多个读操作可以同时进行而不会互相影响。由读表操作加上的锁，加锁后其他用户只能获取该表或行的共享锁，不能获取排它锁，也就是说只能读不能写。 写锁（排它锁）：当当前写操作没有完成之前，它会阻断其他写锁和读锁。由写表操作加上的锁，加锁后其他用户不能获取该表或行的任何锁。 从锁定的数据范围分 表锁：锁定某个表。 行锁 ：锁定某行。 为了尽可能 提高数据库的并发度，每次锁定的数据范围越小越好。理论上每次只锁定当前操作的数据的方案会得到最大的并发度，但是管理锁是很耗费资源的事情。因此数据库系统需要在高并发响应和系统性能两方面进行平衡，这样就产生了“锁粒度”的概念。 锁粒度 表锁：管理锁的开销最小，同时允许的并发量也最小的锁机制。MyIsam存储引擎使用的锁机制。当要写入数据时，把整个表都锁上，此时其他读、写动作一律等待。在MySql中，除了MyIsam存储引擎使用这种锁策略外，MySql本身也使用表锁来执行某些特定动作，比如alter table. 行锁：可以支持最大并发的锁策略。InnoDB和Falcon两张存储引擎都采用这种策略。 MySql是一种开放的架构，你可以实现自己的存储引擎，并实现自己的锁粒度策略，不像Oracle，你没有机会改变锁策略，Oracle采用的是行锁。从大到小，mysql服务器仅支持表级锁，行锁需要存储引擎完成。粒度越精细，并发性越好。即行锁的并发性最好，但需要存储引擎的支持。 数据库事务有不同的隔离级别，不同的隔离级别对锁的使用是不同的，锁的应用最终导致不同事务的隔离级别。 事务和锁机制是什么关系？ 开启事务就自动加锁了吗？ 1、事务与锁是不同的。事务具有ACID（原子性、一致性、隔离性和持久性），锁是用于解决隔离性的一种机制。 2、事务的隔离级别通过锁的机制来实现。另外锁有不同的粒度，同时事务也是有不同的隔离级别的。 3、开启事务就自动加锁。 ql规范定义的事务的隔离级别： 1.READ UNCOMMITTED(读取未提交内容) 所有事务可以看到未提交事务的执行结果，本隔离级别很少用到实际应用中，读取未提交的数据，又称为“脏读”。 2.READ COMMITTED（读取提交内容） 大多数数据库的默认隔离级别是此级别，但不是MySQL默认的。一个事务在开始的时候只能看见已提交事务所做的改变。一个事务从开始到提交前所做的任何改变都是不可见的，除非提交。这种隔离级别也称为不可重复读。 3.REPEATABLE READ(可重复读) 此隔离级别是为了解决不可重复读隔离级别导致的问题即一个事务多个实例并发读取数据时会看到不同的结果。可重复读描述的是一个事务在处理数据时，多次查询此数据得到的结果是一样的。MySQL的InnoDB存储引擎通过多版本并发控制（Multi_Version Concurrency Control, MVCC）机制来解决该问题。不过理论上，这会导致另一个棘手的问题：幻读 （Phantom Read）。简单的说，幻读指当用户读取某一范围的数据行时， 另一个事务又在该范围内插入了新行，当用户再读取该范围的数据行时，会发现有新的“幻影” 行。（幻读描述的是MVCC不能阻止插入新的数据，导致多次查询时数据记录不一致。） 4.SERIALIZABLE(可串行化) 可串行化是最高的隔离级别，它通过强制事务排序，使之不可重读，解决了幻读的问题。此隔离级别会在每个读的数据行上加共享锁，使用这种隔离级别会产生大量的超时现象，一般实际开发中不会用到。该类型在A客户端操作test.test1表时会锁定该数据，如果B客户端想要操作test.test1就需要等待A客户端释放。 这四种隔离级别采取不同的锁类型来实现，若读取的是同一个数据的话，就容易发生问题。例如： 脏读(Drity Read)：某个事务已更新一份数据，另一个事务在此时读取了同一份数据，由于某些原因，前一个RollBack了操作，则后一个事务所读取的数据就会是不正确的。 不可重复读(Non-repeatable read):在一个事务的两次查询之中数据不一致，这可能是两次查询过程中间插入了一个事务更新的原有的数据。 幻读(Phantom Read):在一个事务的两次查询中数据笔数不一致，例如有一个事务查询了几列(Row)数据，而另一个事务却在此时插入了新的几列数据，先前的事务在接下来的查询中，就会发现有几列数据是它先前所没有的。 mysql加锁机制: 根据类型可分为共享锁（SHARED LOCK）和排他锁（EXCLUSIVE LOCK）或者叫读锁（READ LOCK）和写锁（WRITE LOCK）。 根据粒度划分又分表锁和行锁。表锁由数据库服务器实现，行锁由存储引擎实现。 mysql提供了3种事务型存储引擎，InnDB、NDB Cluster和Falcon。 一个事务执行的任何过程中都可以获得锁，但是只有事务提交或回滚的时候才释放这些锁。这些都是隐式锁定，也可以显式锁定，InnoDB支持显式锁定，例如： SELECT …. LOCK IN SHARE MODE (加共享锁) SELECT …..FOR UPDATE(加排他锁) ...

MySQL int 长度 “浮点型"的长度是用来限制数字存储范围的. 比如 float(3,2) 只能够写入 0.00~999.99. “整型"的长度并不会限制存储的数字范围. 比如, int 和 int(3) 的存储范围都是 -2147483648 ~ 2147483647, int unsigned 和 int(3) unsigned 的存储范围都是0 ~ 4294967295. “整型"的长度实际上可以理解为"显示长度”, 如果该字段开启 “Zerofill/补零"就能很明显地知道它的作用. 参考 “高性能MySQL” 的说明 “高性能MySQL” 书中在"4.1 选择优化的数据类型"中提到: MySQL 可以为整数类型指定宽度, 例如 INT(11), 对大多数应用这是没有意义的: 它不会限制值的合法范围, 只是规定了 MySQL 的一些交互工具(例如 MySQL 命令行客户端)用来显示字符的个数. 对于存储和计算来说, INT(1) 和 INT(20) 是相同的 “MySQL 手册"的说明 MySQL 5.7 手册 “12.2.5 Numeric Type Attributes”: MySQL supports an extension for optionally specifying the display width of integer data types in parentheses following the base keyword for the type. For example, INT(4) specifies an INT with a display width of four digits. This optional display width may be used by applications to display integer values having a width less than the width specified for the column by left-padding them with spaces. (That is, this width is present in the metadata returned with result sets. Whether it is used or not is up to the application.) ...

聚合函数 aggregation function, UNION, UNION ALL 聚合函数 (aggregation function) -也就是组函数 在一个行的集合 (一组行) 上进行操作,对每个组给一个结果。 集合查询操作 union 去重 union用于把两个或者多个select查询的结果集合并成一个 默认情况下,UNION = UNION DISTINCT 进行合并的两个查询,其SELECT列表必须在数量和对应列的数据类型上保持一致; 默认会去掉两个查询结果集中的重复行；默认结果集不排序； 最终结果集的列名来自于第一个查询的SELECT列表 union all 不去重 UNION ALL 不去掉结果集中重复的行 SELECT ... UNION [ALL | DISTINCT] SELECT ... [UNION [ALL | DISTINCT] SELECT ...] 常用的组函数: AVG([distinct] expr) 求平均值 COUNT({*|[distinct] } expr) 统计行的数量 MAX([distinct] expr) 求最大值 MIN([distinct] expr) 求最小值 SUM([distinct] expr) 求累加和 ①每个组函数接收一个参数 ②默认情况下,组函数忽略列值为null的行,不参与计算 ③有时,会使用关键字distinct剔除字段值重复的条数 注意: 当使用组函数的select语句中没有group by子句时,中间结果集中的所有行自动形成一组,然后计算组函数； 组函数不允许嵌套,例如: count(max(…))； 组函数的参数可以是列或是函数表达式； ...

时间序列数据库 存储大量时间相关的数据(如日志，用户行为等) 创造了一种新型的数据库分类——时间序列数据库(Time Series Database). 时间序列数据库主要用于指处理带时间标签 (按照时间的顺序变化，即时间序列化）的数据，带时间标签的数据也称为时间序列数据。 influxdb influxdb是最新的一个时间序列数据库,最新一两年才产生,但已经拥有极高的人气。influxdb 是用Go写的,现在v0.9正在开发中,之前开源出来的最稳定的版本是0.88的,但是0.8X是没有集群方案的,但在0.9中会加入进来。 0.9版本的influxdb对于之前会有很大的改变,后端存储有LevelDB换成了BoltDB,读写的API也是有了很大的变化,也将支持集群化,continuous query,支持retention policy,读写性能也是哇哇的,可以说是时间序列存储的完美方案,但是由于还很年轻,可能还会存在诸多的问题,就像现在正在开发的0.9一样,发布一拖再拖,就是由于还有些技术壁垒没有攻陷。 对于influxdb我不想多说些什么,之后打算开一个专题,专门详细来说一说这个玩意,因为我看国内几乎没有详细的文章来讲influxdb的。 http://www.opscoder.info/tsdb.html 对于时间序列的存储,一般会采用专门的时间序列数据库,而不会去使用MySQL或是mongo(但zabbix就是用的MySQL,所以它在IO上面遇到了瓶颈)。现在时间序列的数据库是有很多的,比如graphite、opentsdb以及新生的influxdb。最近也相继研究了一下这三个数据库,现在把研究所得记录下来。 特性： 高效的时间序列数据写入性能。自定义TSM引擎，快速数据写入和高效数据压缩。 无额外存储依赖。 简单，高性能的HTTP查询和写入API。 以插件方式支持许多不同协议的数据摄入，如：graphite，collectd，和openTSDB SQL-like查询语言，简化查询和聚合操作。 索引Tags，支持快速有效的查询时间序列。 保留策略有效去除过期数据。 连续查询自动计算聚合数据，使频繁查询更有效。 influxDB 不支持数据库的更新操作，毕竟时间数据只能随着时间产生新数据，肯定无法对过去的数据修改。 适合于写多读少的场景 graphite graphite算是一个老牌的时间序列存储解决方案了,graphite由三个部分组成,分别是carbon、whisper和graphite web carbon:实际上是一系列守护进程,这些守护进程用Twisted的事件驱动网络引擎监听时间序列数据。Twisted框架让Carbon守护进程能够以很低的开销处理大量的客户端和流量。 whisper:是一个用于存储时间序列数据的数据库,之后应用程序可以用create,update和fetch操作获取并操作这些数据。 graphite web:使用django开发的一套web,提供一些常用的聚合函数,可以界面友好的展示出图形。再盗图: whisper支持RRD,可以很方便的定义retention,以及定义storage scheme,不需要手动做,graphite会自动帮你按照不同的scheme实现aggregation。这样每个metric的大小就是固定的了,所以理论上可以永久存储数据。graphite的集群方案主要有两种,分别是使用graphite自带的relay或是使用第三方的工具。 当使用自带的relay时,只需要在配置文件中配置要relay到哪些机器即可,这样在数据写入的时候,被写入的节点会relay一份到这些机器中。在读取的时候,在graphite web的settings中配置HOSTS的列表,这样在django的web中会依次从这些HOSTS中读出数据。 另一种是需用第三方的relay工具,Booking公司开源出来了他们所用的用C写得 carbon-c-relay,以及用GO写得carbon-relay-ng。其基本的思想是运用一致性哈希,可以将不同的metric发到不同的机器,以来达到集群的目的,据Booking称他们的graphite集群的规模达到了百台机器,而mertic也达到了百万的级别. 以上的两种方式都会遇到了一个共同的问题,就是集群扩容的问题,我不知道Booking是怎么来解决这个问题的,但是我这边目前是想到了几种方式,这个在我前一篇的文章中已经阐述了: graphite集群扩容方案探究,在这里就先不赘述了。 最后说一下,除了集群问题以外,graphite的还有一性能问题就是读的性能稍差,这决定于其存储的方式,其实在读的时候会去读whisper文件(虽然在django层做了缓存,但是缓存的功能比较弱),通过seek的方式来获取数据的位置,在将数据取出。 opentsdb Opentsdb是一个基于Hbase的时间序列数据库 (新版也支持Cassandra）。 其基于Hbase的分布式列存储特性实现了数据高可用，高性能写的特性。受限于Hbase，存储空间较大，压缩不足。依赖整套 HBase, ZooKeeper 采用无模式的tagset数据结构(sys.cpu.user 1436333416 23 host=web01 user=10001) 结构简单，多value查询不友好 HTTP-DSL查询 opentsdb是一个比较重的时间序列解决方案,为什么说他重呢？因为它的组成是这样的: 可以看到opentsdb所依赖的存储是Hbase集群。TSD在其中担任的责任是IO部分,TSD其实就是一个后台的daemon,一般我会会用一组TSD达成一个TSD的集群 (其实不能算是集群) ,没有master/slave之分,也没有共享状态,然后在之前用LB设备来做负载均衡,官方比较推荐的是用varnish。 当让后端的存储也可以用其他的例如hadoop,但是官方还是建议用Hbase,因为opentsdb就是Hbase社区孵化出来的产品。那么问题来了,Hbase的运维将是一个艰巨的任务,这个依赖于 zookeeper 搭建的集群的坑还是很多的,我看了一下官方文档就有上千页。这里面的优化维护需要有专业的Hbase专家才能完成。 另外opentsdb做不到graphite那样自动做downsample,也就是做不到RRD那样地去存储数据,需要在外面自己做一层手动干这活,再把聚合后的数据写入Hbase,唉,还真是一个费时费力的活。 除此之外opentsdb还是很不错的,读写性能挺高,而且支持tag,支持ttl,支持各种聚合函数。现在很多的监控的metric的存储都是用的opentsdb,嗯,是的,只要有能力玩转还是个不错的选择。 Timescale 基于传统关系型数据库postgresql改造的时间序列数据库 一款兼容sql的时序数据库， 底层存储架构在postgresql上。 作为一个postgresql的扩展提供服务。 ...

sql basic between and BETWEEN 用以查询确定范围的值，这些值可以是数字，文本或日期 。 BETWEEN 运算符是闭区间的：包括开始 和 结束值 。 not between 则是不包含前后边界的 select select * from table0 where column0!=''; !=’’ 会过滤掉值为 null 的数据. The reason is simple: nulls are neither equal, nor not equal, to anything. This makes sense when you consider that null means “unknown”, and the truth of a comparison to an unknown value is also unknown. The corollary is that: null = null is not true null = some_value is not true null != some_value is not true The two special comparisons IS NULL and IS NOT NULL exist to deal with testing if a column is, or is not, null. No other comparisons to null can be true. ...

InfluxDB 时间序列数据库 InfluxDB 基于 Go 语言开发,社区非常活跃,项目更新速度很快,日新月异,关注度高。 特点 可以设置metric的保存时间。 支持通过条件过滤以及正则表达式删除数据。 支持类似 sql 的语法。 可以设置数据在集群中的副本数。 支持定期采样数据,写入另外的measurement,方便分粒度存储数据。 概念 数据格式 Line Protocol measurement[,tag_key1=tag_value1…] field_key=field_value[,field_key2=field_value2] [timestamp] cpu_load,host_id=1 value=0.1 1434055562000000000 相比于 JSON 格式,无需序列化,更加高效。 measurement: metric name,例如 cpu_load。 field-key, field-value: 通常用来存储数据,类似 opentsdb 中的 value=0.6,但是支持各种类型,数据存储时不会进行索引,每条数据必须拥有一个 field-key,如果使用 field-key 进行过滤,需要遍历一遍所有数据。 tags-key, tags-value: 和 field-key 类似,但是会进行索引,方便查询时用于过滤条件。 Series measurement, tag set, retention policy 相同的数据集合算做一个 series。 假设 cpu_load 有两个 tags,host_id 和 name,host_id 的数量为 100,name 的数量为 200,则 series 基数为 100 * 200 = 20000。 ...

MVCC, Multiversion Concurrency Control, 多版本并发控制 http://donghui.blog.51cto.com/2709336/692586 多版本并发控制技术已经被广泛运用于各大数据库系统中,如 Oracle, MS SQL Server 2005+, Postgresql, Firebird, Maria 等等, 开源数据库 MySQL 中流行的 INNODB 引擎也采用了类似的并发控制技术.本文就将结合实例来解析不同事务隔离等级下 INNODB 的 MVCC 实现原理. 1.1 MVCC 简介 MVCC (Multiversion Concurrency Control), 即多版本并发控制技术, 它使得大部分支持行锁的事务引擎, 不再单纯的使用行锁来进行数据库的并发控制, 取而代之的是, 把数据库的行锁与行的多个版本结合起来, 只需要很小的开销, 就可以实现非锁定读, 从而大大提高数据库系统的并发性能. 1.2 实现原理 MVCC 可以提供基于某个时间点的快照, 使得对于事务看来, 总是可以提供与事务开始时刻相一致的数据, 而不管这个事务执行的时间有多长. 所以在不同的事务看来, 同一时刻看到的相同行的数据可能是不一样的, 即一个行可能有多个版本. 是否听起来不可思议呢? 原来, 为了实现 mvcc, innodb 对每一行都加上了两个隐含的列, 其中一列存储行被更新的"时间", 另外一列存储行被删除的"时间". 但是 innodb 存储的并不是绝对的时间, 而是与时间对应的数据库系统的版本号, 每当一个事务开始的时候, innodb 都会给这个事务分配一个递增的版本号, 所以版本号也可以被认为是事务号. 对于每一个"查询"语句, innodb 都会把这个查询语句的版本号同这个查询语句遇到的行的版本号进行对比, 然后结合不同的事务隔离等级, 来决定是否返回该行. ...

MySQL explain, 执行计划, Query Execution Plan 关于explain命令相信大家并不陌生,具体用法和字段含义可以参考官网explain-output,这里需要强调rows是核心指标,绝大部分rows小的语句执行一定很快 (有例外,下面会讲到) 。所以优化语句基本上都是在优化rows。 在日常工作中,我们会有时会开慢查询去记录一些执行时间比较久的SQL语句,找出这些SQL语句并不意味着完事了,些时我们常常用到explain这个命令来查看一个这些SQL语句的执行计划,查看该SQL语句有没有使用上了索引,有没有做全表扫描,这都可以通过explain命令来查看。所以我们深入了解MySQL的基于开销的优化器,还可以获得很多可能被优化器考虑到的访问策略的细节,以及当运行SQL语句时哪种策略预计会被优化器采用。 (QEP: sql生成一个执行计划query Execution plan) MySQL> explain select * from servers; +—-+————-+———+——+—————+——+———+——+——+——-+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +—-+————-+———+——+—————+——+———+——+——+——-+ | 1 | SIMPLE | servers | ALL | NULL | NULL | NULL | NULL | 1 | NULL | +—-+————-+———+——+—————+——+———+——+——+——-+ 1 row in set (0.03 sec) expain出来的信息有10列,分别是 id、select_type、table、type、possible_keys、key、key_len、ref、rows、Extra,下面对这些字段出现的可能进行解释: ...

redis data type, 数据类型 https://redis.io/topics/data-types https://redis.io/topics/data-types-intro String - 字符串 List - 列表 Set - 无序集合 Hashes - 哈希/散列表 Sorted sets - 有序集合 Stream - 消息队列 Bitmaps, url: redis-bitmap HyperLogLogs Hyperloglog https://segmentfault.com/a/1190000020523110 geospatial https://blog.csdn.net/zhang197093/article/details/72979038

redis hash Redis hash 是一个 string 类型的 field和 value的映射表.一个 key可对应多个 field, 一个 field对应一个 value。将一个对象存储为 hash类型,较于每个字段都存储成string类型更能节省内存。新建一个 hash对象时开始是用 zipmap(又称为small hash)来存储的。这个 zipmap其实并不是 hash table,但是zipmap 相比正常的 hash实现可以节省不少 hash本身需要的一些元数据存储开销。尽管 zipmap的添加, 删除,查找都是O(n),但是由于一般对象的field数量都不太多。所以使用zipmap也是很快的,也就是说添加删除平均还是O(1)。如果field或者value的大小超出一定限制后,Redis会在内部自动将zipmap替换成正常的hash实现。 hash操作命令如下: 删除 key del key hset 向名称为 key 的 hash 中添加元素 hset key field value hget hget(key, field) 返回名称为key的hash中field对应的value hsetnx HSETNX key field value 将哈希表key中的域field的值设置为value,当且仅当域field不存在。若域field已经存在,该操作无效。 如果key不存在,一个新哈希表被创建并执行h#setnx命令。 hmget hmget(key, field1, …,field N) 返回名称为key的hash中field i对应的value hmset hmset(key, field1, value1,…,field N, value N) 向名称为key的hash中添加元素field i<—>value i ...

内存数据库 内存数据库,顾名思义就是将数据放在内存中直接操作的数据库。相对于磁盘,内存的数据读写速度要高出几个数量级,将数据保存在内存中相比从磁盘上访问能够极大地提高应用的性能。 内存数据库抛弃了磁盘数据管理的传统方式,基于全部数据都在内存中重新设计了体系结构,并且在数据缓存、快速算法、并行操作方面也进行了相应的改进,所以数据处理速度比传统数据库的数据处理速度要快很多,一般都在10倍以上。内存数据库的最大特点是其"主拷贝"或"工作版本"常驻内存,即活动事务只与实时内存数据库的内存拷贝打交道。 定义:设有数据库系统DBS,DB为DBS中的数据库,DBM(t)为在时刻t,DB在内存的数据集,DBM(t)属于DB。TS为DBS中所有可能的事务构成的集合。AT(t)为在时刻t处于活动状态的事务集,AT(t)属于TS。Dt(T)为事务T在时刻t所操作的数据集, Dt(T)属于DB。若在任意时刻t,均有: 任意T属于AT(t) Dt(T)属于DBM(t) 成立,则称DBS为一个内存数据库系统,简称为MMDBS;DB为一个内存数据库,简称为MMDB。 常见的例子有MySQL的MEMORY存储引擎、eXtremeDB、TT、FastDB、SQLite、Microsoft SQL Server Compact,Redis http://baike.baidu.com/view/1210875.htm

sql 的四舍五入取整问题 转自: http://hi.baidu.com/yahuudang/blog/item/4c65ab77f758b01fb151b953.html 经在sql server 2005测试，可以通过 SELECT CAST(‘123.456’ as decimal) 将会得到 123 (小数点后面的将会被省略掉) 。 如果希望得到小数点后面的两位。 则需要把上面的改为 SELECT CAST(‘123.456’ as decimal(38, 2)) ===>123.46 自动四舍五入了！ 自己的例子: select CAST(AmountRmb as decimal(38)) as heji,CAST(NotFinFee as decimal(38)) as whx,* from Bill_Tab

FOR XML PATH http://www.cnblogs.com/doubleliang/archive/2011/07/06/2098775.html FOR XML PATH 有的人可能知道有的人可能不知道，其实它就是将查询结果集以XML形式展现，有了它我们可以简化我们的查询语句实现一些以前可能需要借助函数活存储过程来完成的工作。那么以一个实例为主. 一.FOR XML PATH 简单介绍 那么还是首先来介绍一下FOR XML PATH ，假设现在有一张兴趣爱好表 (hobby) 用来存放兴趣爱好，表结构如下: 接下来我们来看应用FOR XML PATH的查询结果语句如下: SELECT * FROM @hobby FOR XML PATH 结果: 复制代码 1 爬山 2 ...

go epoll https://colobu.com/2019/02/23/1m-go-tcp-connection/ https://speakerdeck.com/eranyanay/going-infinite-handling-1m-websockets-connections-in-go https://github.com/smallnest/1m-go-tcp-server https://www.freecodecamp.org/news/million-websockets-and-go-cc58418460bb https://github.com/mailru/easygo https://colobu.com/2015/05/22/implement-C1000K-servers-by-spray-netty-undertow-and-node-js/ https://colobu.com/2015/07/14/performance-comparison-of-7-websocket-frameworks/

SELECT INTO 和 INSERT INTO SELECT 两种表复制语句 Insert是T-sql中常用语句，Insert INTO table(field1,field2,…) values(value1,value2,…)这种形式的在应用程序开发中必不可少。但我们在开发、测试过程中，经常会遇到需要表复制的情况，如将一个table1的数据的部分字段复制到table2中，或者将整个table1复制到table2中，这时候我们就要使用SELECT INTO 和 INSERT INTO SELECT 表复制语句了。 1.INSERT INTO SELECT语句 语句形式为: Insert into Table2(field1,field2,…) select value1,value2,… from Table1 要求目标表Table2必须存在，由于目标表Table2已经存在，所以我们除了插入源表Table1的字段外，还可以插入常量。示例如下: -1.创建测试表 create TABLE Table1 ( a varchar(10), b varchar(10), c varchar(10), CONSTRAINT [PK_Table1] PRIMARY KEY CLUSTERED ( a ASC ) ) ON [PRIMARY] create TABLE Table2 ( a varchar(10), c varchar(10), d int, CONSTRAINT [PK_Table2] PRIMARY KEY CLUSTERED ( a ASC ) ) ON [PRIMARY] GO -2.创建测试数据 ...

update join, delete join UPDATE t1 SET t1.CalculatedColumn = t2.[Calculated Column] FROM dbo.Table1 AS t1 INNER JOIN dbo.Table2 AS t2 ON t1.CommonField = t2.[Common Field] WHERE t1.BatchNo = '110'; DELETE a from t0 a JOIN t1 b ON a.c0=b.c0 WHERE b.c1='xxx' http://stackoverflow.com/questions/1980738/sql-delete-with-join-another-table-for-where-condition http://stackoverflow.com/questions/652770/delete-with-join-in-MySQL/29204958#29204958

concat 和其他数据库系统类似，Oracle字符串连接使用"||“进行字符串拼接，其使用方式和MSSQLServer中的加号”+“一样。 比如执行下面的SQL语句: SELECT ‘工号为’||FNumber||‘的员工姓名为’||FName FROM T_Employee WHERE FName IS NOT NULL 除了”||"，Oracle还支持使用CONCAT()函数进行字符串拼接，比如执行下面的SQL语句: SELECT CONCAT(‘工号:’,FNumber) FROM T_Employee 如果CONCAT中连接的值不是字符串，Oracle会尝试将其转换为字符串，比如执行下面的SQL语句: SELECT CONCAT(‘年龄:’,FAge) FROM T_Employee 与MySQL的CONCAT()函数不同，Oracle的CONCAT()函数只支持两个参数，不支持两个以上字符串的拼接，比如下面的SQL语句在Oracle中是错误的: SELECT CONCAT(‘工号为’,FNumber,‘的员工姓名为’,FName) FROM T_Employee WHERE FName IS NOT NULL 运行以后Oracle会报出下面的错误信息: 参数个数无效 如果要进行多个字符串的拼接的话，可以使用多个CONCAT()函数嵌套使用，上面的SQL可以如下改写: SELECT CONCAT(CONCAT(CONCAT(‘工号为’,FNumber),‘的员工姓名为’),FName) FROM T_Employee WHERE FName IS NOT NULL

number integer 建表的时候,如果是浮点数,一般设置为 number(m,n )[m为精度,n为小数位数,所以整数为m-n位], 整数设置为integer; 比如: create table abc ( a number(38,0), b number(38) c integer, d number ) 那么a,b,c,d 分别有什么区别呢? a,b其实是一样的,都是38位的范围； c是不是和a,b一样呢?测试后是不一样的,c的最大值可以达到9e125,显然远远地大于38位的范围； d和a,b,c有什么区别呢,首先d可以放小数,另外它的范围同样远远大于38位； 具体这a,b,c,d四种类型的明确差异,我也说不清楚,希望有专家把它解释清楚,我这里只是抛砖引玉。 以前我一直以为 integer=number(38,0) -38是number的最大精度 刚才无意中发现integer 是个超大的数据类型,最大可以表示为power(10,126)-1 也就是说这么大的数字,大概需要多少个字节呢, 因为一个字节最大表示256,那么N个字节最大表示power(256,n)>=power(10,126) 现在求这个N: 解法是: select LOG(256,10)*126 from dual 求得的解是 53, 也就是说,一个integer类型最少使用53个字节。 所以我觉得Integer类型还是尽量少用,一般很少用到这么大的数字； 特别是某些人对于boolean类型的处理； 因为Oracle的表结构中没有布尔类型,所以很多人干脆用integer 代替布尔类型,这个感觉有点"奢侈"； 我一般都用char(1) 表示布尔型；‘0’表示false,‘1’表示true 另外,比如varchar2(200)这个类型,它是动态分配的,所以字符串按实际使用的占用空间,但是integer却是固定暂用了最少53个字节,所以大部分时候,integer 类型还是不用为妙； 就算在pl/sql 里； 定义变量的时候,也不要使用integer; 可以用binary_integer 或pls_integer ；11g里还出了个新的整形,效率更高,叫simple_integer,反正最好不用integer就是了。 效率测试下来: simple_integer>pls_integer>binary_integer>integer; SIMPLE_INTEGER Subtype of PLS_INTEGER SIMPLE_INTEGER is a predefined subtype of the PLS_INTEGER data type that has the same range as PLS_INTEGER and has a NOT NULL constraint (explained in“NOT NULL Constraint”). It differs significantly from PLS_INTEGER in its overflow semantics. ...