postgresql和mysql(大家常用哪个MySQL客户端工具)

一、SQL Studio

一款免费、支持数据库多、安装使用简单、性能不错的web版管理工具

MySQL8.0.31-arm64使用的工具：SQL Studio操作系统：Mac os 12.11、SQL Studio简介：

操作界面简洁易用，很多人性化小细节，性能稳定

添加数据源

图形化界面支持对数据库对象直接操作，顶部搜索可定位到表、函数等

执行SQL语句

编辑框支持智能提示，可以根据我们输入的字符及语意提示表名等信息；当我们写完SQL语句后点击执行即可运行展示结果，如果有问题可以随时cancel修改。

结果栏默认最多展示1000行数据，列宽自适应,还可以选择每列的排序规则，可以选择需要展示和锁定的列，右下角可以选择每页展示多少条数据，左上角双击“结果”或者放大可以全屏观看数据，很人性化了。

一键解释执行

解释执行：帮助我们分析sql语句的性能，很方便。

保存SQL语句

保存的sql语句会在下方保存的查询中显示，支持搜索，双击复用；还可以在个人中心编辑、修改、删除。

个人中心中展示保存的SQL语句

数据导出

结果栏旁边有一个下载按钮，可以将数据导出；有csv和excel两种格式。

“结果数据”导出是指将结果栏展示的数据导出，因为结果栏默认最多展示1000行，所以“结果数据”导出最多1000行；

“在线导出”是指将SQL语句执行后的所有数据进行导出，我们最多可以导出20万行，下载数据的行为会记录在右边的历史导出中。

在线导出

可以查看表时直接对表结构、表中数据进行修改：

表属性和表数据

直接修改表结构

SQL界面显示对应修改背后的SQL语句，方便使用

直接修改表中数据

鼠标悬停在表右边的三个点，我们除了查看，也能直接导出数据；还可以让工具自动生成一些简单的SQL语句模版；还可以在操作前提前复制表，以免出现错误；最后就是重命名；删除和刷新。

直接生成SQL语句

先写这么多吧～

这个问题其实没有什么好说的。你知道UBER在此之前还有过一次从MYSQL转向PostgreSQL的故事吗？

换了技术老大玩不转了又换回了mysql，哈哈哈。

开个玩笑(但是也不是没有可能哟~~)

至于提到的什么写放大，事物实现不科学等问题，完全是因为根本没有对postgresql进行调优。德哥已经针对这个问题写过好几个文章针对所提出的问题每一点都做了详细的解答和优化方案。

至于说postgresql升级繁琐，这个认。但是postgresql10支持了逻辑复制模式，以后升级就不会那么繁琐了。

脱离业务场景，空谈技术架构都是耍流氓。

我们公司同一个项目就同时在用Mysql和MongoDB，希望通过下面介绍可以帮助你真正了解到Mysql和MongoDB优劣对比及实际业务应用场景。

数据库人气排行

以下来自最新的db-engines的数据库人气排行榜

接下来我们看一下前十名的趋势变化图：

关系数据库前10名如下：

文档数据库前10名如下：

通过上面可以看出MongoDB虽说分数一直保持着稳定上升的趋势，但和 Mysql相比依然有一定的差距。不过，MongoDB 在2018年的表现是非常不错的，至少一直都在进步，这个表现也是 MongoDB 独一份。

数据结构

MySQL：MySQL将数据存储在表中，并使用结构化查询语言（SQL）访问数据。MySQL使用模式来定义数据库结构，要求表中的所有行具有相同的结构，并且值由特定的数据类型表示。

MongoDB：在MongoDB中，数据存储在类似JSON的文档中，这些文档可以有不同的结构。为了提高查询速度，MongoDB可以将相关数据存储在一起，这些数据可以使用MongoDB查询语言访问。

在MongoDB中，文档能够拥有自己独特的结构。新字段可以随时添加并包含任何类型的值。

优缺点

MySQL是关系型数据库。

优势：

在不同的引擎上有不同的存储方式。

查询语句是使用传统的sql语句，拥有较为成熟的体系，成熟度很高。

开源数据库的份额在不断增加，mysql的份额页在持续增长。

缺点：

在海量数据处理的时候效率会显著变慢。

Mongodb是非关系型数据库(nosql )，属于文档型数据库。

存储方式：虚拟内存+持久化。

查询语句：是独特的Mongodb的查询方式。

适合场景：事件的记录，内容管理或者博客平台等等。

架构特点：可以通过副本集，以及分片来实现高可用。

数据处理：数据是存储在硬盘上的，只不过需要经常读取的数据会被加载到内存中，将数据存储在物理内存中，从而达到高速读写。

成熟度与广泛度：新兴数据库，成熟度较低，Nosql数据库中最为接近关系型数据库，比较完善的DB之一，适用人群不断在增长。

优点：

快速！在适量级的内存的Mongodb的性能是非常迅速的，它将热数据存储在物理内存中，使得热数据的读写变得十分快。高扩展性，存储的数据格式是json格式！

缺点：

事务关系支持薄弱。这也是所有NoSQL数据库共同的缺陷，不过NoSQL并不是为了事务关系而设计的，具体应用还是根据需求。而且开发文档不是很完全、完善。

应用场景

关系型数据库适合存储结构化数据，如用户的帐号、地址

1）这些数据通常需要做结构化查询，比如join，这时候，关系型数据库就要胜出一筹

2）这些数据的规模、增长的速度通常是可以预期的

3）事务性、一致性

NoSQL适合存储非结构化数据，如文章、评论：

1）这些数据通常用于模糊处理，如全文搜索、机器学习

2）这些数据是海量的，而且增长的速度是难以预期的，

3）根据数据的特点，NoSQL数据库通常具有无限（至少接近）伸缩性

4）按key获取数据效率很高，但是对join或其他结构化查询的支持就比较差

什么场景MongoDB更适用

更高的写入负载

默认情况下，MongoDB更侧重高数据写入性能，而非事务安全，MongoDB很适合业务系统中有大量“低价值”数据的场景。但是应当避免在高事务安全性的系统中使用MongoDB，除非能从架构设计上保证事务安全。

高可用性

MongoDB的复副集(Master-Slave)配置非常简洁方便，此外，MongoDB可以快速响应的处理单节点故障，自动、安全的完成故障转移。这些特性使得MongoDB能在一个相对不稳定（如云主机）的环境中，保持高可用性。

数据量很大或者未来会变得很大

依赖数据库(MySQL)自身的特性，完成数据的扩展是较困难的事，在MySQL中，当一个单达表到5-10GB时会出现明显的性能降级，此时需要通过数据的水平和垂直拆分、库的拆分完成扩展，使用MySQL通常需要借助驱动层或代理层完成这类需求。而MongoDB内建了多种数据分片的特性，可以很好的适应大数据量的需求。

基于位置的数据查询

MongoDB支持二维空间索引，因此可以快速及精确的从指定位置获取数据。

表结构不明确，且数据在不断变大

在一些传统RDBMS中，增加一个字段会锁住整个数据库/表，或者在执行一个重负载的请求时会明显造成其它请求的性能降级。通常发生在数据表大于1G的时候（当大于1TB时更甚）。因MongoDB是文档型数据库，为非结构货的文档增加一个新字段是很快速的操作，并且不会影响到已有数据。另外一个好处当业务数据发生变化时，是将不在需要由DBA修改表结构。

没有DBA支持

如果没有专职的DBA，并且准备不使用标准的关系型思想（结构化、连接等）来处理数据，那么MongoDB将会是你的首选。MongoDB对于对像数据的存储非常方便，类可以直接序列化成JSON存储到MongoDB中。但是需要先了解一些最佳实践，避免当数据变大后，由于文档设计问题而造成的性能缺陷。

实际业务应用

BillRun – 基于MongoDB的帐单系统 (来自oc666)

BillRun是由Ofer Cohen推出开源账单系统，采用MongoDB做为数据存储。这套账单系统被以色列一家增速最快的电信运营商采用，每月处理5亿条通信记录，Ofer在Slideshare上说明了具体利到了MongoDB的哪些特性：

弱数据结构的特点，使得BillRun能很快的支持新的CDR(通讯记录)类型。这个特性使文档型数据库很适用于快速发展、业务需求不确定的系统中。

BillRun仅使用了一个Collection，已经管理了数TB的文档数据，并且没有遇到由结构变更、数据爆发式增长的带来的限制和问题。

replicaSet副本集特性使建立更多的数据中心DRP变得更轻松。

内建的Sharding分片特性避免系统在数据增长的过程中遇到性能瓶颈。

每秒钟2000条通信记录的插入，MongoDB在架构设计上很好的支持了高负载的数据写入。并且可以使用findAndModify(相对缓慢)完成基础的事务特性，并且通过应用层面的支持，实现双段式提交。

查询方式相比SQL，更加易读、易懂，开发相对轻松。

基于位置允许更好的分析用户使用情况，从而更好地制定移动电话基础设施的投入点。