您的位置:

首页 >

5060官方网址大全 >

5060官方网址大全:Redis中五种数据类型简单操作 >

5060官方网址大全:Redis中五种数据类型简单操作

2016-02-03 09:33:56

分类:5060官方网址大全

Redis中五种数据类型简单操作提出问题Redis五种数据类型的简单增删改查命令???解决问题假设你已经安装Redis服务器; 假设你已经打开Redis cli命令行工具; 假设你对Redis有所了解;Redis简单增删改查例子例一:字符串的增删改查#增加一个key为ay_key的值127.0.0.1:6379> set ay_key "ay"OK#查询ay_key的值127.0.0.1:6379> get ay_key"ay"#修改ay_key的值127.0.0.1:6379> set ay_key "new_ay"OK127.0.0.1:6379> get ay_key"new_ay"#修改ay_key名称127.0.0.1:6379> rename ay_key new_ay_keyOK127.0.0.1:6379> keys *1) "new_ay_key"#删除ay_key127.0.0.1:6379> del ay_key(integer) 0#查询是否存在ay_key 0127.0.0.1:6379> exists ay_key(integer) 0例二:Set集合的增删改查#删除当前选择数据库中的所有key127.0.0.1:6379> flushdbOK#生成set集合,添加4个数据127.0.0.1:6379> sadd set_ay_key "ay" "al" "xy" "xl"(integer) 4#查询set里面所有值127.0.0.1:6379> smembers set_ay_key1) "xy"2) "al"3) "ay"4) "xl"#删除value为"xl" , 返回 1 如果没有返回 0127.0.0.1:6379> srem set_ay_key "xl"(integer) 1127.0.0.1:6379> smembers set_ay_key1) "xy"2) "al"3) "ay"#添加value为"xl"127.0.0.1:6379> sadd set_ay_key "xl"(integer) 1127.0.0.1:6379> smembers set_ay_key1) "xy"2) "al"3) "ay"4) "xl"#添加value为"xl" 添加不进去,但也不报错,set是不允许重复的127.0.0.1:6379> sadd set_ay_key "xl"(integer) 0#不多解释127.0.0.1:6379> sadd set_ay_key "xl"(integer) 0#不多解释127.0.0.1:6379> sadd set_ay_key "xl"(integer) 0例三:List集合的增删改查#添加key为list_ay_key的list集合127.0.0.1:6379> lpush list_ay_key "ay" "al" "xy" "xl"(integer) 4#查询key为list_ay_key的集合127.0.0.1:6379> lrange list_ay_key 0 -11) "xl"2) "xy"3) "al"4) "ay"#往list尾部添加元素127.0.0.1:6379> rpush list_ay_key "together"(integer) 5#往list头部添加元素127.0.0.1:6379> lpush list_ay_key "first"(integer) 6#查询list集合127.0.0.1:6379> lrange list_ay_key 0 -11) "first"2) "xl"3) "xy"4) "al"5) "ay"6) "together"#更新index为0的值 127.0.0.1:6379> lset list_ay_key 0 "update_first"OK127.0.0.1:6379> lrange list_ay_key 0 -11) "update_first"2) "xl"3) "xy"4) "al"5) "ay"6) "together"#删除index为1上的值127.0.0.1:6379> lrem list_ay_key 1 "update_first"(integer) 1127.0.0.1:6379> lrange list_ay_key 0 -11) "xl"2) "xy"3) "al"4) "ay"5) "together"例四:Hash集合(类似Java)的增删改查127.0.0.1:6379> flushdbOK#生成hash集合,并添加key 为uuid_one value 为"12345"127.0.0.1:6379> hset hash_ay_key "uuid_one" "12345"(integer) 1127.0.0.1:6379> hlen hash_ay_key(integer) 1#返回集合所有的key127.0.0.1:6379> hkeys hash_ay_key1) "uuid_one"#返回集合所有value127.0.0.1:6379> hvals hash_ay_key1) "12345"#集合添加值127.0.0.1:6379> hset hash_ay_key "uuid_two" "22222"(integer) 1#集合添加值127.0.0.1:6379> hset hash_ay_key "uuid_three" "33333"(integer) 1#获得key为uuid_one的值127.0.0.1:6379> hget hash_ay_key uuid_one"12345"#删除key为uuid_three的值127.0.0.1:6379> hdel hash_ay_key uuid_three(integer) 1127.0.0.1:6379> hkeys hash_ay_key1) "uuid_one"2) "uuid_two"#获得所有,包括key和value127.0.0.1:6379> hgetall hash_ay_key1) "uuid_one"2) "12345"3) "uuid_two"4) "22222"#更新key为uuid_one的值127.0.0.1:6379> hset hash_ay_key uuid_one "11111"(integer) 0127.0.0.1:6379> hset hash_ay_key "uuid_one" "11111"(integer) 0127.0.0.1:6379> hgetall hash_ay_key1) "uuid_one"2) "11111"3) "uuid_two"4) "22222"例五:SortedSet集合的增删改查SortedSet是有序的set集合#sorted set添加值ay 排序值为 1127.0.0.1:6379> zadd zset_ay_key 1 "ay"(integer) 1127.0.0.1:6379> zadd zset_ay_key 2 "al"(integer) 1127.0.0.1:6379> zadd zset_ay_key 3 "xy"(integer) 1127.0.0.1:6379> zadd zset_ay_key 4 "xl"(integer) 1#查询所有的值127.0.0.1:6379> zrange zset_ay_key 0 -11) "ay"2) "al"3) "xy"4) "xl"#删除所有的值127.0.0.1:6379> zrem zet_ay_key "xl"(integer) 0127.0.0.1:6379> zrange zset_ay_key 0 -11) "ay"2) "al"3) "xy"4) "xl" 感谢阅读,希望能帮助到大家,谢谢大家对本站的支持!

文章作者:jhkdiy 发表日期:2009-10-11 程序架构:B/S 开发环境:Windows XP + IIS6 + VS2003 数 据 库:SQL Server 2000 部分功能:从 SQL Server 中导出数据到 Access。 这套系统做了大半年,这个导入导出还是问题不断,我负责的这块导入导出就是夹在网 络版和单机版系统之间,只要任何一边对数据库做了改动这个导入导出就会失败。哎,烦心 的事不止这些,最近又遇到了一个非常奇怪的问题。 由于之前的导入导出使用SQL Server 支持的OpenDataSource()函数来做,而当遇到 64位系统时就会遇到不支持Microsoft.Jet.OLEDB.4.0 ,所以重新编码,技术步骤是先从SQL Server 读数据到DataTable,然后遍历这个DataTable,对每一行,将里面的数据重新组合成一条Insert 语句,然后打开Access文件链接,执行刚才生成的Insert语句,将数据插入到Access中。 我最终提交给Access执行的语句是根据SQL Server中的数据拼出来,比如SQL Server :select a, b, c from tblTemp 提交给Access执行的语句就是: 复制代码 代码如下: Str1 = “Insert into” Str2 = “tblTemp(a,b,c)values(” strResult = str1 & str2 & “‘aa', 2, ‘cc' ” & “)” 这回的重大问题是在SQL Server 表的b字段中有特殊字符,此字符使我的程序无法拼出完整的字符串,拼出来的字符串strResult 有时不带最后的“)”,但奇怪的是,这个表总共有4万多条记录,只是组合个别记录才会出现这个现象。但是提交给Access执行肯定不通过,提示SQL语法错误。 我于是查询数据库的这条记录,用查询分析器查询没发现任何的特殊字符,问了同事后才知道,他说之前有过部分表中的某些字符保存了客户输入的回车换行符,我顿时大悟,对呀,回车换行符是看不见的啊,于是,想使用下面的语句查询字段中是否有回车换行符: 复制代码 代码如下: select charindex(char(10), demc) from tblgc_jc_de where xh = 15641 select charindex(char(13), demc) from tblgc_jc_de where xh = 15641 select charindex(char(10) + char(13), demc) from tblgc_jc_de where xh = 15641 select charindex(char(13) + char(10), demc) from tblgc_jc_de where xh = 15641 但奇怪的是,返回都是0,也就是找不到。这就郁闷了,字段中到底存储了什么字符啊?,另一个同事教了一招,直接在企业管理器中返回该表的所有行记录,然后全选查看该字段,发现确实是多出一个字符: 不是回车换行符会是什么字符呢?在百思不解之际,突然想起,不如看看这个表物理数据,一定能查出存储在该字段的是什么字符。但是该表有44022条记录,查某一条记录的物理数据就是大海捞针,怎么办??? 我只想查询这条记录的物理数据要怎么做?能不能把这条数据放到另一个表中,这个表只有这一条记录,这不就可以查看了吗。哦,这个简单,其实我同时建立了一个临时的数据库,这个数据库只有一张表,这张表只有一条记录,就是包含上面那个有问题的记录,使用的SQL语句如下: -- TYZW 是正式库 use TYZW -- 创建一个临时数据库,然后将有问题的那条 -- 记录插入临时库。 create database tmpTYZW go select * into tmpTYZW..tblgc_jc_de from tblgc_jc_de where xh = 15641 go 现在是时候查看一下这条记录的物理数据了,首先要在sysindexes系统表中查找出该表在物理文件中的位置,然后我们可以通过 dbcc page 命令查看物理数据:接着使用dbcc page命令查看物理数据:现在是时候看看这条记录的物理数据了: 天啊,竟然是0,真不晓得是怎么存进去的。问题终于知道在那了,但是要如何解决呢?最简单的方法就是将这个0替换掉,于是使用下列语句测试:select replace(demc, char(0), '') as demc from tblgc_jc_de 但是不行,原因是replace函数找不到0这个字符,因为它查找是按两个字节来找的,所以直接在SQL Server上找也找不到这个字符,替换也替换不了。但是,我又想了一下,能不能使用二进制来查找和替换?看了一下资料,使用下面的SQL语句能找出0在该字段的位置:查是能查出来了,但是我发现replace函数还是不能用,除非是替换4位,也就是0x0038。最后实在无奈,只能直接把有这个特殊字符的地段截掉一个文字,也就是连那个38也不要了:select case  when charindex(convert(varbinary(1),0x00),convert(varbinary(200),demc)) > 0         then substring(demc,1,len(demc)-1)         else demc          end as DEMC from tblgc_jc_de 这就是我现在用的最终解决方案,因为我查询过,4万多条记录中只有8条有这个0在字段里面。所以就算截掉一个文字并影响程序的功能和显示。虽然我现在写出来很多步骤看似走的很顺,其实这个问题我用了几天时间了,主要是找问题所在耗费了不少时间。现在给出此文希望广大朋友在找这些问题时多个方向,因为存储在字段中的特殊字符不一定就是常规的回车换行符,也有可能是其它字符,在此大家互相学习提高吧。

使用下以两种方法时必须把字段设为”主键(PRIMARY KEY”或”唯一约束(UNIQUE)”。1:使用REPLACE INTO (此种方法是利用替换的方法,有点似类于先删除再插入)  复制代码 代码如下:REPLACE INTO Syntax  REPLACE [LOW_PRIORITY | DELAYED]      [INTO] tbl_name [(col_name,...)]      {VALUES | VALUE} ({expr | DEFAULT},…),(…),…  Or:  REPLACE [LOW_PRIORITY | DELAYED]      [INTO] tbl_name      SET col_name={expr | DEFAULT}, …  Or:  REPLACE [LOW_PRIORITY | DELAYED]      [INTO] tbl_name [(col_name,...)]      SELECT … 2:使用INSERT [IGNORE] INTO (此种方法效率比较高,判断是否存在,存在不插入,否则插入)  复制代码 代码如下:INSERT [IGNORE] INTO Syntax  INSERT [LOW_PRIORITY | DELAYED | HIGH_PRIORITY] [IGNORE]  [INTO] tbl_name [(col_name,

如下: 复制代码 代码如下: SELECT * FROM Orders WHERE OrderGUID IN('BC71D821-9E25-47DA-BF5E-009822A3FC1D','F2212304-51D4-42C9-AD35-5586A822258E') 可以看出直接在IN后面跟ID的集合需要将每一个ID都用单引号引起来。在实际应用中会遇到这么一种情况,在界面中收集的是一串GUID的拼接字符串,中间以逗号隔开,如果作为参数传到一个存储过程中执行,最终生成的语句会是下面这样: 复制代码 代码如下: SELECT * FROM Orders WHERE OrderGUID IN('BC71D821-9E25-47DA-BF5E-009822A3FC1D,F2212304-51D4-42C9-AD35-5586A822258E') 这样就不能查询到正确的结果。 一般情况下我们解决此问题的思路是将传入的字符串用一个split函数来处理,最终处理的结果是一张表,然后将这个表做自查询即可,如下: 复制代码 代码如下: DECLARE @IDs VARCHAR(4000) SET @IDs='BC71D821-9E25-47DA-BF5E-009822A3FC1D,F2212304-51D4-42C9-AD35-5586A822258E' DECLARE @temp TABLE(str VARCHAR(50)) INSERT INTO @temp SELECT * FROM dbo.Split(@IDs,',') SELECT * FROM Orders WHERE OrderGUID IN (SELECT str FROM @temp) 当然split函数系统比不提供,需要我们自己写: 复制代码 代码如下: CREATE FUNCTION Split ( @SourceSql varchar(8000), @StrSeprate varchar(10) ) RETURNS @temp TABLE(F1 VARCHAR(100)) AS BEGIN DECLARE @i INT SET @SourceSql=rtrim(ltrim(@SourceSql)) SET @i=charindex(@StrSeprate,@SourceSql) WHILE @i>=1 BEGIN INSERT @temp VALUES(left(@SourceSql,@i-1)) SET @SourceSql=substring(@SourceSql,@i+1,len(@SourceSql)[email protected]) SET @i=charindex(@StrSeprate,@SourceSql) END IF @SourceSql<>'' INSERT @temp VALUES(@SourceSql) RETURN END 像这样做非常麻烦,而且还需要借助函数来实现,下面介绍一种简单的方法,因为GUID是唯一的,所以在上面的例子中可以使用LIKE来代替IN也可以达到同样的查询效果: 复制代码 代码如下: SELECT * FROM Orders WHERE 'BC71D821-9E25-47DA-BF5E-009822A3FC1D,F2212304-51D4-42C9-AD35-5586A822258E' LIKE '%'+convert(VARCHAR(40),

MySQL5.6有很多新的特性,其中很多人都感兴趣的一条就是全局事务序号功能(GTIDs)。而大家都对这一特性很感兴趣的原因也很好理解,即:本来重新连接从服务器和一个新的主服务器一直是件很麻烦的事,然而在启用GTIDs功能之后就变得简单易行。可是,GTIDs的使用不单单是用单独的标识符替换旧的二进制日志文件/位置,它也采用了新的复制协议。假如你还不太明白这些,那你可以在这篇文章里学点什么。复制协议:新的 VS 旧的 旧的协议往往简单直接即:首先从服务器上在一个特定的偏移量那里连接到一个给定的二进制日志文件,然后主服务器在从那里发送所有的事务。新协议稍有不同:slave首先会发送它已经执行过的GTID的范围,然后master发送每一个丢失的事务. 它也确保了一个给定的GTID只可以在一个特定的slave中执行一次.实践中,这会改变任何东西吗? 使得,它会改变很多东西. 想象一下下面的场景: 你想要从trx 4开始复制,但是trx2在slave上因为某种缘故丢失了.  使用老协议的话,trx 2再也不会被执行一次,而使用新协议,它就会被自动的再执行一次.下面是两个你可以在实践中看到新协议的通用场景.跳过事务众所周知老的 SET GLOBAL sql_slave_skip_counter = N 在你想要跳过一个事务时不再提供支持,而GTID就可以被启用了. 换用 GTID XXX:N 来跳过事务, 你须得 注入一个空的事务: mysql> SET gtid_next = 'XXX:N';mysql> BEGIN; COMMIT;mysql> SET gtid_next = 'AUTOMATIC';为什么我们不能使用 sql_slave_skip_counter? 就是因为新的复制协议!想象一下我们拥有如下图所示的三台服务器:  让我们假设 sql_slave_skip_counter 可以用并且已经被用在S2上用于跳过trx2. 如果你吧S2设置成S1的一个slave将会发生什么呢?两个服务器会互相交换被执行了GTID的范围,并且S1将会意识到其必须将trx2发送给S2. 然后会发生的事情有两种可能:     如果 trx 2 仍然在S1的二进制日志中,它将会被发送给S2,而事务在也不会被跳过了.     如果 trx 2 不再存在于S1的二进制日志中,你将会得到一个复制错误.很明显这不安全,这就是为什么 sql_slave_skip_counter 在使用GTID时是不能用的. 要想跳过一个事务,唯一安全的选择就是去执行一个虚拟的事务,而不是一个真实的事务. 错误的事务如果你在一个slave上本地执行了一个事务 (在MySQL文档中被称为错误事务), 如果你被这个事务推送到新的master上时会发生什么呢?使用老协议,基本上没啥事(准确点说,新的master和其slave之间的数据将会出现不一致,但那在稍后就可能会被修复).使用新协议,错误的事务将会被识别成为在每个地方都丢失了,并且将会自动在容错备份上被执行,这样就将会导致打断复制的隐患.比方说,你拥有一个master(M)和两个slave (S1 和 S2). 这里有两种将slave重连到新的master将会发生(带有不同复制错误的)失败的场景:# 场景 1 # S1mysql> CREATE DATABASE mydb;# Mmysql> CREATE DATABASE IF NOT EXISTS mydb;# Thanks to 'IF NOT EXITS', replication doesn't break on S1. Now move S2 to S1:# S2mysql> STOP SLAVE; CHANGE MASTER TO MASTER_HOST='S1'; START SLAVE;# This creates a conflict with existing data!mysql> SHOW SLAVE STATUS\G[...]Last_SQL_Errno: 1007 Last_SQL_Error: Error 'Can't create database 'mydb'; database exists' on query. Default database: 'mydb'. Query: 'CREATE DATABASE mydb'[...]# 场景 2 # S1mysql> CREATE DATABASE mydb;# Now, we'll remove this transaction from the binary logs# S1mysql> FLUSH LOGS;mysql> PURGE BINARY LOGS TO 'mysql-bin.000008';# Mmysql> CREATE DATABASE IF NOT EXISTS mydb;# S2mysql> STOP SLAVE; CHANGE MASTER TO MASTER_HOST='S1'; START SLAVE;# The missing transaction is no longer available in the master's binary logs!mysql> SHOW SLAVE STATUS\G[...]Last_IO_Errno: 1236 Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'[...]你可以这样理解,错误的事务应该借助基于GTID的服务得以避免. 如果你需要运行一个本地事务,最好的选择是针对那条特定的语句禁用二进制日志: mysql> SET SQL_LOG_BIN = 0;mysql> # Run local transaction结论GTIDs在让我们方便重新和其他服务器连接副本方面是个不小的进步。然而同样的在运维方面我们也因此面临新的困难和挑战。假如你打算开始使用GTIDs,那么你就得确实理解新的复制协议,否则你就会以一种想不到的方式结束复制过程。

焦点访谈

最新最热的文章

更多 >

COPYRIGHT (©) 2017 Copyright ©2017 5060网址大全 网站地图

联系我们

827570882

扫描二维码分享到微信