AI 助理
备案控制台

AA大大官_个人页

AA大大官
个人头像照片
文章
1
问答
33
视频
0

个人介绍

Java程序员

擅长的技术

  • 数据库
获得更多能力
通用技术能力：

暂时未有相关通用技术能力~

云产品技术能力：

暂时未有相关云产品技术能力~

阿里云技能认证

详细说明
暂无更多信息

2021年03月

2020年03月

  • 发表了文章 2017-11-13

    Java多线程编程-（18）-借ThreadLocal出现OOM内存溢出问题再谈弱引用WeakReference

正在加载, 请稍后...
滑动查看更多
  • 回答了问题 2021-03-09

    表必备的三字段是哪些？

    主键ID，创建时间、修改时间
    踩0 评论0
  • 回答了问题 2021-03-09

    简述Zookeeper是什么

    Zookeeper官网地址： http://zookeeper.apache.org/ Zookeeper官网文档地址：http://zookeeper.apache.org/doc/trunk/index.html ZooKeeper 是Hadoop下的一个子项目，它是一个针对大型分布式系统的可靠协调系统；它提供的功能包括：配置维护、名字服务、分布式同步、组服务等； 它的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。 Zookeeper一个最常用的使用场景就是用于担任服务生产者和服务消费者的注册中心，服务生产者将自己提供的服务注册到Zookeeper中心，服务的消费者在进行服务调用的时候先到Zookeeper中查找服务，获取到服务生产者的详细信息之后，再去调用服务生产者的内容与数据，简单示例图如下：
    踩0 评论0
  • 回答了问题 2021-03-09

    简述在Java语言中IO的方式通常分为几种

    1、OIO中，每个线程只能处理一个channel（同步的，该线程和该channel绑定）。 线程发起IO请求，不管内核是否准备好IO操作，从发起请求起，线程一直阻塞，直到操作完成,如图： 2、NIO中，每个线程可以处理多个channel（异步）。 线程发起IO请求，立即返回；内核在做好IO操作的准备之后，通过调用注册的回调函数通知线程做IO操作，线程开始阻塞，直到操作完成 3、AIO中，线程发起IO请求，立即返回；内存做好IO操作的准备之后，做IO操作，直到操作完成或者失败，通过调用注册的回调函数通知线程做IO操作完成或者失败
    踩0 评论0
  • 回答了问题 2021-03-09

    简述Java语言中，什么是序列化与反序列化

    1、什么是序列化和反序列化 （1）Java序列化是指把Java对象转换为字节序列的过程，而Java反序列化是指把字节序列恢复为Java对象的过程； （2）**序列化：**对象序列化的最主要的用处就是在传递和保存对象的时候，保证对象的完整性和可传递性。序列化是把对象转换成有序字节流，以便在网络上传输或者保存在本地文件中。序列化后的字节流保存了Java对象的状态以及相关的描述信息。序列化机制的核心作用就是对象状态的保存与重建。 （3）**反序列化：**客户端从文件中或网络上获得序列化后的对象字节流后，根据字节流中所保存的对象状态及描述信息，通过反序列化重建对象。 （4）本质上讲，序列化就是把实体对象状态按照一定的格式写入到有序字节流，反序列化就是从有序字节流重建对象，恢复对象状态。 2、为什么需要序列化与反序列化 我们知道，当两个进程进行远程通信时，可以相互发送各种类型的数据，包括文本、图片、音频、视频等， 而这些数据都会以二进制序列的形式在网络上传送。 那么当两个Java进程进行通信时，能否实现进程间的对象传送呢？答案是可以的！如何做到呢？这就需要Java序列化与反序列化了！ 换句话说，一方面，发送方需要把这个Java对象转换为字节序列，然后在网络上传送；另一方面，接收方需要从字节序列中恢复出Java对象。 当我们明晰了为什么需要Java序列化和反序列化后，我们很自然地会想Java序列化的好处。其好处一是实现了数据的持久化，通过序列化可以把数据永久地保存到硬盘上（通常存放在文件里），二是，利用序列化实现远程通信，即在网络上传送对象的字节序列。 总的来说可以归结为以下几点： （1）永久性保存对象，保存对象的字节序列到本地文件或者数据库中； （2）通过序列化以字节流的形式使对象在网络中进行传递和接收； （3）通过序列化在进程间传递对象； 3、序列化算法一般会按步骤做如下事情： （1）将对象实例相关的类元数据输出。 （2）递归地输出类的超类描述直到不再有超类。 （3）类元数据完了以后，开始从最顶层的超类开始输出对象实例的实际数据值。 （4）从上至下递归输出实例的数据
    踩0 评论0
  • 回答了问题 2021-03-09

    简述AIO与NIO的区别

    1、OIO中，每个线程只能处理一个channel（同步的，该线程和该channel绑定）。 线程发起IO请求，不管内核是否准备好IO操作，从发起请求起，线程一直阻塞，直到操作完成,如图： 2、NIO中，每个线程可以处理多个channel（异步）。 线程发起IO请求，立即返回；内核在做好IO操作的准备之后，通过调用注册的回调函数通知线程做IO操作，线程开始阻塞，直到操作完成 3、AIO中，线程发起IO请求，立即返回；内存做好IO操作的准备之后，做IO操作，直到操作完成或者失败，通过调用注册的回调函数通知线程做IO操作完成或者失败
    踩0 评论0
  • 回答了问题 2021-03-09

    为什么使用消息队列？（MQ）

    1.1、提高系统响应速度 使用了消息队列，生产者一方，把消息往队列里一扔，就可以立马返回，响应用户了。无需等待处理结果。 处理结果可以让用户稍后自己来取，如医院取化验单。也可以让生产者订阅（如：留下手机号码或让生产者实现listener接口、加入监听队列），有结果了通知。获得约定将结果放在某处，无需通知。 1.2、提高系统稳定性 考虑电商系统下订单，发送数据给生产系统的情况。电商系统和生产系统之间的网络有可能掉线，生产系统可能会因维护等原因暂停服务。如果不使用消息队列，电商系统数据发布出去，顾客无法下单，影响业务开展。两个系统间不应该如此紧密耦合。应该通过消息队列解耦。同时让系统更健壮、稳定。 1.3、异步化、解耦、消除峰值 以上三点其实可以用一个例子来解释——设想有一款MMO游戏，没有人肉写的缓存层或者ORM，所有逻辑节点都直连MySQL，逻辑节点内除了要关注场景、战斗、交互等复杂逻辑以外，还要有个拼SQL语句的模块，想想简直是蛋疼。先考虑一下这样设计的弊端所在： 逻辑节点与Db的交互会有大量IO，即使把与Db交互的模块耦合在逻辑节点内，其实现对你来说是黑盒，如果内部是同步实现的，那就直接卡你游戏主逻辑，就因为一次存盘操作，玩家们都掉线了，服务器也可以关掉了。 那么我们改进一下，针对1的情况，可以把这个模块做到一个线程里挂在逻辑节点上。这样其实逻辑节点跟这个Db前端模块的交互就会基于一个比较原始的消息队列。但是这样还有一个坏处，那就是这两种任务一种是计算密集的（玩家的逻辑处理）、一种是IO密集的（只负责写入读取MySQL），搞到一个节点中，扩展起来会非常麻烦，而且耦合度太高。比如说现在发现场景放单节点上有瓶颈，要按场景分节点，那么这种挂在上面的数据模块怎么跟其他场景的交互呢？ 峰值的问题。在分布式系统中，一次分布式事务关联的是多个节点，其中每一个节点出现问题都会成为整个事务处理流程中的瓶颈。如果逻辑节点与数据库之间没有一个起到缓冲作用的节点，那就是每次操作都要访问数据库，对于MMO来说，一个玩家上线load几百K数据，一个服10万个玩家上线已经足够搞垮一个mysql节点了。如果直接搞垮还是比较好的结果，至少是前面的玩家确实登录上去了并且可以正常游戏，后面的玩家登录不上。但是很可惜，十年前开始流行的C10K说法就是在讲：并发量上来之后，会造成chain reaction，大量的并发不会直接挂掉你的mysql节点，但是会拖慢速度，降低吞吐量，一个玩家的请求由于处理时间太长，导致玩家放弃重试，但是对于后端来说，对该玩家之前的处理过程消耗的资源就全部浪费了，陷入恶性循环。 所以，这种情景下，一个介于逻辑节点和db节点之间的缓存节点就是理所当然的事情了。这个缓存节点其实很多时候也可以看作是一个更复杂的消息队列节点。
    踩0 评论0
  • 回答了问题 2021-03-09

    程序员如何搭建一个简洁漂亮实用的个人博客？

    推荐：Hexo
    踩0 评论0
  • 回答了问题 2021-03-09

    在varchar字段上建立索引时，要注意什么？

    阿里巴巴开发规范【强制】在varchar字段上建立索引时，必须指定索引长度，没必要对全字段建立索引，根据实际文本区分度决定索引长度即可。 说明：索引的长度与区分度是一对矛盾体，一般对字符串类型数据，长度为20的索引，区分度会高达90%以上，可以使用count(distinct left(列名, 索引长度))/count(*)的区分度来确定。
    踩0 评论0
  • 回答了问题 2021-03-09

    开源的Java博客系统有哪些？

    mblog、Solo、hexo、DoraCMS、Halo、OneBlog等等
    踩0 评论0
  • 回答了问题 2021-03-09

    什么字段必须建成唯一索引？

    参考《阿里巴巴Java开发规范》 【强制】业务上具有唯一特性的字段，即使是多个字段的组合，也必须建成唯一索引。 说明：不要以为唯一索引影响了insert速度，这个速度损耗可以忽略，但提高查找速度是明显的；另外，即使在应用层做了非常完善的校验控制，只要没有唯一索引，根据墨菲定律，必然有脏数据产生。
    踩0 评论0
  • 回答了问题 2021-03-09

    OSS可以存储多少数据，有上限吗？

    OSS总存储容量不限制，单个Bucket容量也不限制。通过OSS控制台仅可以上传小于5 GB的文件。对于大于5 GB的文件，需要使用分片上传和断点续传功能，或者使用图形化工具ossbrowser、命令行工具ossutil直接上传。 可以参考阿里云OSS官方文档：https://help.aliyun.com/document_detail/130345.html
    踩0 评论0
  • 回答了问题 2021-03-09

    OSS适合存储什么？

    1、OSS适合作为应用程序的持久化存储 持久保存文件（附件、图片、视频） RDS数据库MySQL 2、数据处理 图片处理：提供裁剪、旋转、水印、缩放媒体转码：音视频格式转换 3、海量存储 管理音视频资源 网络摄像机直存 4、动静态资源分离 动态资源：数据库记录 静态资源：图片、附件、音视频资源的超低延时传输
    踩0 评论0
  • 回答了问题 2021-03-09

    21天Java打卡活动总结，你坚持学习了几天？

    mark
    踩0 评论0
  • 回答了问题 2020-03-31

    什么是最左前缀原则？什么是最左匹配原则?

    最左前缀原则：顾名思义是最左优先，以最左边的为起点任何连续的索引都能匹配上。 （1）如果第一个字段是范围查询需要单独建一个索引； （2）在创建多列索引时，要根据业务需求，where子句中使用最频繁的一列放在最左边； 当创建(a,b,c)复合索引时，想要索引生效的话，只能使用 a和ab、ac和abc三种组合！ 实例：以下是常见的几个查询： mysql>SELECT `a`,`b`,`c` FROM A WHERE `a`='a1' ; //索引生效 mysql>SELECT `a`,`b`,`c` FROM A WHERE `b`='b2' AND `c`='c2'; //索引失效 mysql>SELECT `a`,`b`,`c` FROM A WHERE `a`='a3' AND `c`='c3'; //索引生效，实际上值使用了索引a 扩展：想要索引最大化的使用需要至少建几个索引？ 答：需要建立复合索引：bc 3.1、三个字段联合索引测试： 联合索引的顺序为：sex，age，name SELECT * FROM user where sex='3'; #使用索引 SELECT * FROM user where age='4'; #未使用索引 SELECT * FROM user where name='2'; #未使用索引 SELECT * FROM user where sex='2' and age='3'; #使用索引 SELECT * FROM user where sex='2' and age='3' and name='4'; #使用索引 SELECT * FROM user where age='3' and name='4'; #未使用索引 SELECT * FROM user where sex='2' and name='4'; #使用索引 #这个在3.2最后边解释，为什么 explain SELECT * FROM index_demo.user where age='2' and sex='3'; #使用索引 值得注意的是，where sex=“2” and name=“4” 这个相当于只有sex使用到了索引的， 和where sex=“2” and age=“3” and name='4'的区别： 3.2、如果索引字段有两个 如果索引有两个字段：sex，age explain SELECT * FROM index_demo.user where sex='3'; #使用索引 explain SELECT * FROM index_demo.user where age='4'; #未使用索引 explain SELECT * FROM index_demo.user where sex='2' and age='3'; #使用索引 explain SELECT * FROM index_demo.user where age='3' and sex='4'; #使用索引 where sex=“2” and age=“3”;和where sex=“2” and age=“3”; 这两个都是用了索引的，这是mysql查询优化器，mysql查询优化器会判断纠正这条sql语句该以什么样的顺序执行效率最高，最后才生成真正的执行计划。所以，当然是我们能尽量的利用到索引时的查询顺序效率最高咯，所以mysql查询优化器会最终以这种顺序进行查询执行。 然后回到刚才的3.1中三个索引的时候：sex，age，name explain SELECT * FROM index_demo.user where age='2' and sex='3'; #使用索引 这条语句竟然使用索引了 可以看出他是使用索引了，因为对于三个索引的时候，只要是前两个，存在，不论顺序是什么都是会使用索引的，这里主要是mysql查询优化器起的作用了； ———————————————— 版权声明：本文为CSDN博主「徐刘根」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/u010870518/java/article/details/79572598
    踩0 评论0
  • 回答了问题 2020-03-31

    数据库为什么使用B+树而不是B树?

    请参考个人博客：https://blog.csdn.net/u010870518/article/details/79450295 在进一步分析为什么MySQL数据库索引选择使用B+树之前，我相信很多小伙伴对数据结构中的树还是有些许模糊的，因此我们由浅入深一步步探讨树的演进过程，在一步步引出B树以及为什么MySQL数据库索引选择使用B+树！ 学过数据结构的一般对最基础的树都有所认识，因此我们就从与我们主题更为相近的二叉查找树开始。 一、二叉查找树 （1）二叉树简介： 二叉查找树也称为有序二叉查找树，满足二叉查找树的一般性质，是指一棵空树具有如下性质： 1、任意节点左子树不为空,则左子树的值均小于根节点的值； 2、任意节点右子树不为空,则右子树的值均大于于根节点的值； 3、任意节点的左右子树也分别是二叉查找树； 4、没有键值相等的节点； 上图为一个普通的二叉查找树，按照中序遍历的方式可以从小到大的顺序排序输出：2、3、5、6、7、8。 对上述二叉树进行查找，如查键值为5的记录，先找到根，其键值是6，6大于5，因此查找6的左子树，找到3；而5大于3，再找其右子树；一共找了3次。如果按2、3、5、6、7、8的顺序来找同样需求3次。用同样的方法在查找键值为8的这个记录，这次用了3次查找，而顺序查找需要6次。计算平均查找次数得：顺序查找的平均查找次数为（1+2+3+4+5+6）/ 6 = 3.3次，二叉查找树的平均查找次数为（3+3+3+2+2+1）/6=2.3次。二叉查找树的平均查找速度比顺序查找来得更快。 （2）局限性及应用 一个二叉查找树是由n个节点随机构成，所以，对于某些情况，二叉查找树会退化成一个有n个节点的线性链。如下图： 大家看上图，如果我们的根节点选择是最小或者最大的数，那么二叉查找树就完全退化成了线性结构。上图中的平均查找次数为（1+2+3+4+5+5）/6=3.16次，和顺序查找差不多。显然这个二叉树的查询效率就很低，因此若想最大性能的构造一个二叉查找树，需要这个二叉树是平衡的（这里的平衡从一个显著的特点可以看出这一棵树的高度比上一个输的高度要大，在相同节点的情况下也就是不平衡），从而引出了一个新的定义-平衡二叉树AVL。 二、AVL树 （1）简介 AVL树是带有平衡条件的二叉查找树，一般是用平衡因子差值判断是否平衡并通过旋转来实现平衡，左右子树树高不超过1，和红黑树相比，它是严格的平衡二叉树，平衡条件必须满足（所有节点的左右子树高度差不超过1）。不管我们是执行插入还是删除操作，只要不满足上面的条件，就要通过旋转来保持平衡，而旋转是非常耗时的，由此我们可以知道AVL树适合用于插入删除次数比较少，但查找多的情况。 从上面是一个普通的平衡二叉树，这张图我们可以看出，任意节点的左右子树的平衡因子差值都不会大于1。 （2）局限性 由于维护这种高度平衡所付出的代价比从中获得的效率收益还大，故而实际的应用不多，更多的地方是用追求局部而不是非常严格整体平衡的红黑树。当然，如果应用场景中对插入删除不频繁，只是对查找要求较高，那么AVL还是较优于红黑树。 （3）应用 1、Windows NT内核中广泛存在； 三、红黑树 （1）简介 一种二叉查找树，但在每个节点增加一个存储位表示节点的颜色，可以是red或black。通过对任何一条从根到叶子的路径上各个节点着色的方式的限制，红黑树确保没有一条路径会比其它路径长出两倍。它是一种弱平衡二叉树(由于是若平衡，可以推出，相同的节点情况下，AVL树的高度低于红黑树)，相对于要求严格的AVL树来说，它的旋转次数变少，所以对于搜索、插入、删除操作多的情况下，我们就用红黑树。 （2）性质 1、每个节点非红即黑； 2、根节点是黑的； 3、每个叶节点(叶节点即树尾端NULL指针或NULL节点)都是黑的； 4、如果一个节点是红的,那么它的两儿子都是黑的； 5、对于任意节点而言，其到叶子点树NULL指针的每条路径都包含相同数目的黑节点； 6、每条路径都包含相同的黑节点； （3）应用 1、广泛用于C++的STL中，Map和Set都是用红黑树实现的； 2、著名的Linux进程调度Completely Fair Scheduler，用红黑树管理进程控制块，进程的虚拟内存区域都存储在一颗红黑树上，每个虚拟地址区域都对应红黑树的一个节点，左指针指向相邻的地址虚拟存储区域，右指针指向相邻的高地址虚拟地址空间； 3、IO多路复用epoll的实现采用红黑树组织管理sockfd，以支持快速的增删改查； 4、Nginx中用红黑树管理timer，因为红黑树是有序的，可以很快的得到距离当前最小的定时器； 5、Java中TreeMap的实现； 四、B/B+树 说了上述的三种树：二叉查找树、AVL和红黑树，似乎我们还没有摸到MySQL为什么要使用B+树作为索引的实现，不要急，接下来我们就先探讨一下什么是B树。 （1）简介 我们在MySQL中的数据一般是放在磁盘中的，读取数据的时候肯定会有访问磁盘的操作，磁盘中有两个机械运动的部分，分别是盘片旋转和磁臂移动。盘片旋转就是我们市面上所提到的多少转每分钟，而磁盘移动则是在盘片旋转到指定位置以后，移动磁臂后开始进行数据的读写。那么这就存在一个定位到磁盘中的块的过程，而定位是磁盘的存取中花费时间比较大的一块，毕竟机械运动花费的时候要远远大于电子运动的时间。当大规模数据存储到磁盘中的时候，显然定位是一个非常花费时间的过程，但是我们可以通过B树进行优化，提高磁盘读取时定位的效率。 为什么B类树可以进行优化呢？我们可以根据B类树的特点，构造一个多阶的B类树，然后在尽量多的在结点上存储相关的信息，保证层数尽量的少，以便后面我们可以更快的找到信息，磁盘的I/O操作也少一些，而且B类树是平衡树，每个结点到叶子结点的高度都是相同，这也保证了每个查询是稳定的。 总的来说，B/B+树是为了磁盘或其它存储设备而设计的一种平衡多路查找树(相对于二叉，B树每个内节点有多个分支)，与红黑树相比，在相同的的节点的情况下，一颗B/B+树的高度远远小于红黑树的高度(在下面B/B+树的性能分析中会提到)。B/B+树上操作的时间通常由存取磁盘的时间和CPU计算时间这两部分构成，而CPU的速度非常快，所以B树的操作效率取决于访问磁盘的次数，关键字总数相同的情况下B树的高度越小，磁盘I/O所花的时间越少。 注意B-树就是B树，-只是一个符号。 （2）B树的性质 1、定义任意非叶子结点最多只有M个儿子，且M>2； 2、根结点的儿子数为[2, M]； 3、除根结点以外的非叶子结点的儿子数为[M/2, M]； 4、每个结点存放至少M/2-1（取上整）和至多M-1个关键字；（至少2个关键字） 5、非叶子结点的关键字个数=指向儿子的指针个数-1； 6、非叶子结点的关键字：K[1], K[2], …, K[M-1]；且K[i] 这里只是一个简单的B树，在实际中B树节点中关键字很多的，上面的图中比如35节点，35代表一个key(索引)，而小黑块代表的是这个key所指向的内容在内存中实际的存储位置，是一个指针。 五、B+树 （1）简介 B+树是应文件系统所需而产生的一种B树的变形树（文件的目录一级一级索引，只有最底层的叶子节点（文件）保存数据）非叶子节点只保存索引，不保存实际的数据，数据都保存在叶子节点中，这不就是文件系统文件的查找吗? 我们就举个文件查找的例子：有3个文件夹a、b、c， a包含b，b包含c，一个文件yang.c，a、b、c就是索引（存储在非叶子节点）， a、b、c只是要找到的yang.c的key，而实际的数据yang.c存储在叶子节点上。 所有的非叶子节点都可以看成索引部分！ （2）B+树的性质(下面提到的都是和B树不相同的性质) 1、非叶子节点的子树指针与关键字个数相同； 2、非叶子节点的子树指针p[i],指向关键字值属于[k[i],k[i+1]]的子树.(B树是开区间,也就是说B树不允许关键字重复,B+树允许重复)； 3、为所有叶子节点增加一个链指针； 4、所有关键字都在叶子节点出现(稠密索引). (且链表中的关键字恰好是有序的)； 5、非叶子节点相当于是叶子节点的索引(稀疏索引),叶子节点相当于是存储(关键字)数据的数据层； 6、更适合于文件系统； 非叶子节点（比如5，28，65）只是一个key（索引），实际的数据存在叶子节点上（5，8，9）才是真正的数据或指向真实数据的指针。 （3）应用 1、B和B+树主要用在文件系统以及数据库做索引，比如MySQL； 六、B/B+树性能分析 n个节点的平衡二叉树的高度为H(即logn)，而n个节点的B/B+树的高度为logt((n+1)/2)+1； 　 若要作为内存中的查找表，B树却不一定比平衡二叉树好，尤其当m较大时更是如此。因为查找操作CPU的时间在B-树上是O(mlogtn)=O(lgn(m/lgt))，而m/lgt>1；所以m较大时O(mlogtn)比平衡二叉树的操作时间大得多。因此在内存中使用B树必须取较小的m。（通常取最小值m=3，此时B-树中每个内部结点可以有2或3个孩子，这种3阶的B-树称为2-3树）。 七、为什么说B+树比B树更适合数据库索引？ 1、 B+树的磁盘读写代价更低：B+树的内部节点并没有指向关键字具体信息的指针，因此其内部节点相对B树更小，如果把所有同一内部节点的关键字存放在同一盘块中，那么盘块所能容纳的关键字数量也越多，一次性读入内存的需要查找的关键字也就越多，相对IO读写次数就降低了。 2、B+树的查询效率更加稳定：由于非终结点并不是最终指向文件内容的结点，而只是叶子结点中关键字的索引。所以任何关键字的查找必须走一条从根结点到叶子结点的路。所有关键字查询的路径长度相同，导致每一个数据的查询效率相当。 3、由于B+树的数据都存储在叶子结点中，分支结点均为索引，方便扫库，只需要扫一遍叶子结点即可，但是B树因为其分支结点同样存储着数据，我们要找到具体的数据，需要进行一次中序遍历按序来扫，所以B+树更加适合在区间查询的情况，所以通常B+树用于数据库索引。 PS：我在知乎上看到有人是这样说的,我感觉说的也挺有道理的： 他们认为数据库索引采用B+树的主要原因是：B树在提高了IO性能的同时并没有解决元素遍历的我效率低下的问题，正是为了解决这个问题，B+树应用而生。B+树只需要去遍历叶子节点就可以实现整棵树的遍历。而且在数据库中基于范围的查询是非常频繁的，而B树不支持这样的操作或者说效率太低。 ———————————————— 版权声明：本文为CSDN博主「徐刘根」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/u010870518/java/article/details/79450295
    踩0 评论0
  • 回答了问题 2020-03-31

    视图的使用场景有哪些？

    用途： 视图根本用途在我看来就一个：简化sql查询，提高开发效率。如果说还有另外一个用途那就是兼容老的表结构。 使用场景： 1）计算列的需要，数据库设计范式要求我们减少冗余字段，因此现在很多数据表都没有计算列字段，如采购单：有价格、数量、税率、含税金额，多半没有不含税金额、税额，而这些字段在很多报表中有都会用到，所以我们可以创建一个含有计算列字段的视图来解决这个问题。 2）不同表字段聚合，信息重组，如：经销商通常有业务员，业务员通常有上下级关系（客户经理、区域经理、大区经理等），因此查看经销商业务员时我们需要看到直管业务员是谁？该业务员对应的区域经理、大区经理是谁（可能NULL）？因此我们可以联合经销商表、业务员信息表、业务员上下级关系表定义一个经销商视图。 3）安全性需要，主要是早期遗留系统集成需要，如：需要xx系统数据，又没接口，怎么办？直接操作数据库，这时就涉及数据安全性，合理利用视图则可以减少很多授权工作和保证数据安全性。当下新构建的系统几乎都是暴露api接口，因此数据安全性更多关注在接口的身份认证和数据粒度方面。 4）兼容老的数据表，曾经碰到过这么个问题。 公司自主研发的进销存管理系统，一开始自用的，后来合作伙伴企业也要用，所以打算Saas化，当初做了一个最大的变动就是几乎所有表增加了一个使用单位(co_id)字段。悲催的是另外一个外购系统用到了采购单表，该系统已经停止维护、又继续在用。于是就创建了一个co_id=自有公司的视图，命名为原采购单表，而原采购单表改成新表名。这样一来外购系统可以继续使用，而且数据也没问题。
    踩0 评论0
  • 回答了问题 2020-03-31

    视图的优点？

    使用数据库视图的优点 - 数据库视图允许简化复杂查询：数据库视图由与许多基础表相关联的SQL语句定义。 您可以使用数据库视图来隐藏最终用户和外部应用程序的基础表的复杂性。 通过数据库视图，您只需使用简单的SQL语句，而不是使用具有多个连接的复杂的SQL语句。 数据库视图有助于限制对特定用户的数据访问。 您可能不希望所有用户都可以查询敏感数据的子集。可以使用数据库视图将非敏感数据仅显示给特定用户组。 数据库视图提供额外的安全层。 安全是任何关系数据库管理系统的重要组成部分。 数据库视图为数据库管理系统提供了额外的安全性。 数据库视图允许您创建只读视图，以将只读数据公开给特定用户。 用户只能以只读视图检索数据，但无法更新。 数据库视图启用计算列。 数据库表不应该具有计算列，但数据库视图可以这样。 假设在orderDetails表中有quantityOrder(产品的数量)和priceEach(产品的价格)列。 但是，orderDetails表没有一个列用来存储订单的每个订单项的总销售额。如果有，数据库模式不是一个好的设计。 在这种情况下，您可以创建一个名为total的计算列，该列是quantityOrder和priceEach的乘积，以表示计算结果。当您从数据库视图中查询数据时，计算列的数据将随机计算产生。 数据库视图实现向后兼容。 假设你有一个中央数据库，许多应用程序正在使用它。 有一天，您决定重新设计数据库以适应新的业务需求。删除一些表并创建新的表，并且不希望更改影响其他应用程序。在这种情况下，可以创建与将要删除的旧表相同的模式的数据库视图。
    踩0 评论0
  • 回答了问题 2020-03-31

    视图的缺点？

    使用数据库视图有几个缺点： 性能：从数据库视图查询数据可能会很慢，特别是如果视图是基于其他视图创建的。 表依赖关系：将根据数据库的基础表创建一个视图。每当更改与其相关联的表的结构时，都必须更改视图。
    踩0 评论0
  • 回答了问题 2020-03-31

    varchar与char的区别？

    1、char(n)类型     char类型时定长的类型，即当定义的是char(10)，输入的是'abc'这三个字符时，它们占的空间一样是10个字节，包括7个空字节。当输入的字符长度超过指定的数时，char会截取超出的字符。而且，当存储char值时，MySQL是自动删除输入字符串末尾的空格。     char是适合存储很短的、一般固定长度的字符串。例如，char非常适合存储密码的MD5值，因为这是一个定长的值。对于非常短的列，char比varchar在存储空间上也更有效率。 2、varchar(n)类型      varchar(n)类型用于存储可变长的，长度为n个字节的可变长度且非Unicode的字符数据。n必须是介于1和8000之间的数值，存储大小为输入数据的字节的实际长度+1/2. 比如varchar(10), 然后输入abc三个字符，那么实际存储大小为3个字节。除此之外，varchar还需要使用1或2个额外字节记录字符串的长度，如果列的最大长度小于等于255字节（是定义的最长长度，不是实际长度），则使用1个字节表示长度，否则使用2个字节来表示。     所以，从空间上考虑，varcahr较合适；从效率上考虑，用char合适。二者之间需要权衡。     除了char和varchar之外，还有一种nchar、nvarchar(n)，包含n个字符的可变长度为unicode字符数据。n的值必须介于1~4000之间，直接的存储大小是说输入字符个数的两倍，所输入的数据字符长度可以为零。从名字上看，多了一个n，表示存储的是unicode数据类型的字符，这是为了存储汉字用的，1个英文字母或者数字占用的字符为1个，一个汉字占用2个字符，那么对于有中英文混合的字符串，我们需要定义nvarchar类型。Unicode字符集就是为了解决字符集这种不兼容的问题而产生的，它所有的字符都用两个字节表示，即英文字符也是用两个字节表示。nchar、nvarchar的长度是在1到4000之间。和char、varchar比较起来，nchar、nvarchar则最多存储4000个字符，不论是英文还是汉字；而char、varchar最多能存储8000个英文，4000个汉字。可以看出使用nchar、nvarchar数据类型时不用担心输入的字符是英文还是汉字，较为方便，但在存储英文时数量上有些损失。所以一般来说，如果含有中文字符，用nchar/nvarchar，如果纯英文和数字，用char/varchar。 还有，text类型。其存储可变长度的非Unicode数据，最大长度为2^31-1(2,147,483,647)个字符。
    踩0 评论0
  • 回答了问题 2020-03-31

    UNION与UNION ALL的区别？

    1、UNION用的比较多。 union all是直接连接，取到得是所有值，记录可能有重复； union 是取唯一值，记录没有重复； 2、效率 UNION和UNION ALL关键字都是将两个结果集合并为一个，但这两者从使用和效率上来说都有所不同。 2.1、对重复结果的处理：UNION在进行表链接后会筛选掉重复的记录，Union All不会去除重复记录。 2.2、对排序的处理：Union将会按照字段的顺序进行排序；UNION ALL只是简单的将两个结果合并后就返回。 从效率上说，UNION ALL要比UNION快很多，所以，如果可以确认合并的两个结果集中不包含重复数据且不需要排序时的话，那么就使用UNION ALL。 3、排序和去重 UNION去重且排序 UNION ALL不去重不排序
    踩0 评论0
正在加载, 请稍后...
滑动查看更多
正在加载, 请稍后...
暂无更多信息