mysql数据库的类型有哪些

说实话，你这段总结挺清晰的，但要说完全搞懂MySQL这些类型，我得先自曝个丑：当年我摸爬滚打论坛的时候，刚接触MySQL集群（就是分布式那套）差点把头发薅秃。
所以今天跟你唠唠，尽量说点实在的。

关系型数据库这块，说实话就是最常见的"表格型"数据库。
我当年接的第一个电商项目，用的就是这种。
订单表、用户表，数据清清楚楚排成行和列。
最有意思的是，搞过一次库存超卖，全靠SQL事务回滚救场——这就是ACID的硬道理。
不过要注意，关系型在处理超大数据量时，查询速度可能会掉链子，我碰见过一次百万级订单查询卡到用户直骂街的情况。

列式存储呢，这个我后来搞大数据分析时才真正摸透。
记得有一次帮客户跑用户画像，传统查询跑半天，换了列式存储的MySlowQuery直接秒出结果。
关键是它只读不写，所以适合报表系统这种不用频繁更新的场景。
不过有个坑，列式存储的写入性能确实不如行式，我试过一次往亿级日志表里批量插入数据，列式直接卡到崩溃。

内存数据库我倒是见过用得出彩的。
某外卖平台搞过一套内存数据库做订单实时计算，确实快得离谱。
但说实话，这种适合场景特别窄——记得有个案例是算用户实时优惠券资格，数据丢失几分钟影响不大。
你要是试试用Memcached存核心交易数据，我劝你先掂量掂量后果。

分布式这块最坑也最牛。
我带团队搞过MySQL NDB Cluster，第一次做分片规则简直像拆炸弹。
后来有个客户把集群搞崩过，数据全丢了，最后还是靠异地备份恢复。
不过分布式的好处是真的香，有次系统大促，单机直接挂了，集群那边自动扩容扛住流量，客户都夸我们技术牛。
但要注意，集群维护成本不低，我见过几个小团队硬要搞三节点集群，结果运维压力直接翻倍。

说到底，这些类型没绝对好坏，关键看用家自己需求。
你想想，要是个简单网站选分布式数据库，那不是杀鸡用牛刀？我建议新人先从关系型练起，再根据项目场景选型。
比如跑大数据分析就别硬拗成内存数据库，搞实时计算也别死磕关系型。

mysql数据库名字怎么看

对，就是这操作。
先打开MySQL控制台，输入密码。

用select database()看当前库，status里找currrentdatabase。

想进库，先show databases，然后use库名。

查库里的表，show库名。

会用SQL了，比如查表，select from 表名。
就这么简单。
你自己看。

怎么使用Mysql Workbench 查询mysql数据库

这就是坑，别用MysqlWorkbench的默认连接方式。

实操提醒：使用Mysql命令行工具连接数据库，更稳定高效。

MySQL如何实现跨数据库查询_有哪些限制和技巧？

哈，说起MySQL的跨数据库查询，这事儿我懂点。
先说第一种方式，就是用“数据库名.表名”这种格式。
这招儿简单，直接在SQL语句里写上数据库名，就能访问不同数据库的表。
比如，你想从db1 的table1 和db2 的table2 里选数据，就可以这样写：SELECT FROM db1 .table1 , db2 .table2 WHERE db1 .table1 .id = db2 .table2 .tid; 但这招儿有条件，得是同一个MySQL服务器上的两个数据库，用户还得有权限。

适用场景嘛，就是同一实例下的多个业务数据库需要联合查询，数据结构稳定，量不大的时候用。
不过，这方式也有问题，比如查询性能可能会受影响，特别是大表关联的时候。

再来说第二种，就是用FEDERATED引擎，这个相当于把远程MySQL服务器上的表映射成本地表，实现跨服务器查询。
启用这个引擎之前，你得确认MySQL支持它，用SHOW ENGINES;命令看一眼，如果FEDERATED是YES或DEFAULT，就可以创建远程表连接了。

优点是能实现跨服务器的数据查询，对应用层透明，就像操作本地表一样。
但缺点也明显，性能比较差，大数据量或频繁写入时表现更明显，不支持事务，配置和维护也麻烦，安全性也要小心，密码可能明文存储。

然后就是那些常见的问题，比如不同服务器的数据不能直接查询，权限控制复杂，性能问题，事务一致性难保证，备份恢复复杂度上升。

解决这些问题，有几个实用技巧。
比如，合并数据库设计，尽量把关联数据放在同一个数据库下；使用视图简化查询，建立一个视图封装跨库查询逻辑；中间层聚合数据，应用层或ETL工具查询不同数据库，然后在中间层合并；定期同步数据，减少跨库查询的频率；使用分库分表中间件，比如MyCat、ShardingSphere等。

说实话，我当时也没想明白这么多细节，但做了这么多年，慢慢也就摸出点门道来了。