zhangjian8641的博客

一、数据库系统架构发展1、主备架构业务发展的前期，数据访问量小，这时我们可以直接采用单库的架构。不过我们一般不使用的上面的架构，因为存在单点的问题。若数据库出现故障，这段期间业务将会不可用。我们除了等待重启，其他没什么解决办法。所以我们会增加一个备库，实时同步主库的数据。一旦「主库」出了故障，通过人工的方式，手动的将「主机」踢下线，将「备机」改为「主机」来继续提供服务。这种架构，部署维护简单，业务开发也无需任何改造。不过缺点也很明显，备库只有在主库有问题的时候才会被启用，存在一定的资源浪费

下面以Mysql来举例说明。SELECT * FROM operation WHERE type = 'SQLStats' AND NAME = 'SlowLog' ORDER BY create_time LIMIT 1000, 10;先看上面这条SQL，是不是就是我们平时写的分页SQL，如果数据库大的时候，我们会在数据库中用 type, name, create_time 字段上加组合索引，以此达到优化的目的。但当 LIMIT 子句变成 “LIMIT 1000000,10” 时，你会发现S

什么是PostgreSQLPostgreSQL 是一个免费的对象-关系数据库服务器(ORDBMS)，完全开源，集关系与非关系于一身。由于前身为加州大学伯克利分校计算机系的学术研究系统，用于商业的时间比较晚，所有国内社区还不是很丰富。数据类型大部分类型与其他SQL差不了太多，主要讲解一下text，json这两个类型，其他类型可以通过下面的官方文档链接进行查看。text：与其他数据库不同，pgsql中的text类型没有长度限制；json：其中有分为json和jsonb，json会输出和输入完全相同的

本篇将介绍Oracle迁移到PgSQL的实战经验，使用的方法是Navicat提供的，具体的方法可行性和操作可以看我之前的介绍。不同数据库之间的数据迁移方案：https://blog.youkuaiyun.com/zhangjian8641/article/details/108377225迁移Oracle数据表结构到Pgsql中在Navicat中找到数据传输，填写源数据和目标数据点击选项只选择传输表结构然后 下一步选择要传输的表 再 下一步等待传输完成 即可。修改表结构1、将有了表结构的Pgsql的表

首先了解一下什么是redis，redis是一个key-value存储系统，支持存储的value的类型包括string(字符串)、list(链表)、set(集合)、zset(sorted set --有序集合)和hash（哈希类型）。当然，redis与其他NoSql的最大不同，就是能够设置超时时间，很多场景都是通过这个来实现的，下面将介绍我知道的几个场景，后续如果有其他的也会补充进来。热点数据缓存由于redis访问速度块、支持的数据类型比较丰富，所以redis很适合用来存储热点数据。将关系型数据库中查询

最近项目有可能从oracle转到pgsql，这中间就会涉及到数据库的迁移，网上搜了一下，发现都是在说用Ora2Pg进行转换，我在服务器上怎么装都没装成功，就想还有没有别的方法。然后无意中想到以前用Navicat传输数据，就去看了一下，发现Navicat还真的提供数据库迁移功能。步骤：打开Navicat -> 工具 -> 数据传输迁移后的结构样子：有问题的数据：其中发现NUMBER的数据迁过来都变成1000位的0了，至于有没有其他的问题，待后续慢慢了解，至少知道这个方法是可行的。这

在线安装 RPM包yum install https://download.postgresql.org/pub/repos/yum/reporpms/EL-6-x86_64/pgdg-redhat-repo-latest.noarch.rpm安装客户端软件包yum install postgresql12安装服务器软件包yum install postgresql12-server启动service postgresql-12 initdbchkconfig postgresql-12 o

当把一个数值类型存成了字符串，如何对该字符串进行数值比较。先上mongodb中的数据结构：db.test1.insert({ "modelId": "111", "patientId": "222", "patientName": "333", "sex": "14", "birthday": "2020-08-06", "count": "10"})现在我们要写一个查询语句，查询出count > 2的SQL，正常我们都会想到 $gt

最近用Oracle开发，发现Oracle跟Mysql还是有很多细微之处不一样，例如本文记录的IN的内容不能大于1000条的问题，我在mysql好像没有遇到过，之前只听说IN语句混影响性能。好的，废话不多说，遇到这个问题，我找了几种方法处理：一、拆分SQL最简单的方法，将总集合拆分为每999个为一集合，每个集合单独一条SQL查询，将每个查询结果用UNION ALL合并起来。SELECT * FROM T_USER WHERE USER_ID IN ('114664882678267904',