mysql数据库查询
1、首先Win+R组合键，输入cmd。
⑵ mysql数据库查询的格式化
DROP
TEMPORARY
TABLE
IF
EXISTS
TABLE_1;
CREATE
TEMPORARY
TABLE
TABLE_1
(
SELECT
*
FROM
(
SELECT
'100YUAN'
vMoney,'5REN'
vNum,'2015-09-15'
vDate
UNION
ALL
SELECT
'200YUAN','6REN','2015-09-21'
)a
);
DROP
TEMPORARY
TABLE
IF
EXISTS
TABLE_2;
CREATE
TEMPORARY
TABLE
TABLE_2
(
SELECT
*
FROM
(
SELECT
'2015-09-15'
vDate
UNION
ALL
SELECT
'2015-09-16'
UNION
ALL
SELECT
'2015-09-17'
UNION
ALL
SELECT
'2015-09-18'
UNION
ALL
SELECT
'2015-09-19'
UNION
ALL
SELECT
'2015-09-20'
UNION
ALL
SELECT
'2015-09-21'
UNION
ALL
SELECT
'2015-09-22'
UNION
ALL
SELECT
'2015-09-23'
UNION
ALL
SELECT
'2015-09-24'
)
a
);
SELECT
a.vDate,IFNULL(b.vMoney,0)
vMoney,IFNULL(b.vNum,0)
vNum
FROM
TABLE_2
a
LEFT
JOIN
TABLE_1
b
ON
a.vDate
=
b.vDate
ORDER
BY
a.vDate
⑶ 如何查看mysql数据库操作记录日志
这是一个慢查询日志的展示工具，能够帮助 DBA 或者开发人员分析数据库的性能问题，给出全面的数据摆脱直接查看 slow-log。QAN（Query Analytics）
PMM 目前有 2 个版本，但是对于 QAN 来说其大致由三部分组成：
QAN-Agent（client）：负责采集 slow-log 的数据并上报到服务端
QAN-API（server）：负责存储采集的数据，并对外提供查询接口
QAN-APP：专门用来展示慢查询数据的 grafana 第三方插件
1. 数据流转
slow-log --> QAN-Agent --> QAN-API <--> QAN-APP（grafana）
2. pmm1 架构图
⑷ 如何提高上百万级记录MySQL数据库查询速度
先安装 Apache Spark，查询数据库的速度可以提升10倍。
在已有的 MySQL 服务器之上使用 Apache Spark （无需将数据导出到 Spark 或者 Hadoop 平台上），这样至少可以提升 10 倍的查询性能。使用多个 MySQL 服务器（复制或者 Percona XtraDB Cluster）可以让我们在某些查询上得到额外的性能提升。你也可以使用 Spark 的缓存功能来缓存整个 MySQL 查询结果表。
思路很简单：Spark 可以通过 JDBC 读取 MySQL 上的数据，也可以执行 SQL 查询，因此我们可以直接连接到 MySQL 并执行查询。那么为什么速度会快呢？对一些需要运行很长时间的查询（如报表或者BI），由于 Spark 是一个大规模并行系统，因此查询会非常的快。MySQL 只能为每一个查询分配一个 CPU 核来处理，而 Spark 可以使用所有集群节点的所有核。在下面的例子中，我们会在 Spark 中执行 MySQL 查询，这个查询速度比直接在 MySQL 上执行速度要快 5 到 10 倍。
另外，Spark 可以增加“集群”级别的并行机制，在使用 MySQL 复制或者 Percona XtraDB Cluster 的情况下，Spark 可以把查询变成一组更小的查询（有点像使用了分区表时可以在每个分区都执行一个查询），然后在多个 Percona XtraDB Cluster 节点的多个从服务器上并行的执行这些小查询。最后它会使用map/rece 方式将每个节点返回的结果聚合在一起形成完整的结果。
⑸ mysql查看数据库所在位置
1.mysql查看数据库位置的语法: show variables like 'datad...
2.命令行模式下登录到mysql
3.键入指令:
4.确认指令无误,回车执行,即可看到数据库存放位置
5.方法二:在mysql配置文件中查看 END
⑹ 如何查看mysql数据库操作记录日志
有时候我们会不小心对一个大表进行了 update，比如说写错了 where 条件......
此时，如果 kill 掉 update 线程，那回滚 undo log 需要不少时间。如果放置不管，也不知道 update 会持续多久。
那我们能知道 update 的进度么？
实验
我们先创建一个测试数据库：
那我们怎么准确的这个倍数呢？
一种方法是靠经验：update 语句的 where 中会扫描多少行，是否修改主键，是否修改唯一键，以这些条件来估算系数。
另一种方法就是在同样结构的较小的表上试验一下，获取倍数。
这样，我们就能准确估算一个大型 update 的进度了。
⑺ mysql数据库查询问题去掉逗号
cast(100000.0000 as decimal(15,2))
convert(value, decimal(12,2))
两者都行
⑻ 如何查看mysql数据库用户密码
1、打开mysql.exe和mysqld.exe所在的文件夹,复制路径地址
⑼ 如何查看mysql数据库隔离级别
术式之后皆为逻辑，一切皆为需求和实现。希望此文能从需求、现状和解决方式的角度帮大家理解隔离级别。
隔离级别的产生
在串型执行的条件下，数据修改的顺序是固定的、可预期的结果，但是并发执行的情况下，数据的修改是不可预期的，也不固定，为了实现数据修改在并发执行的情况下得到一个固定、可预期的结果，由此产生了隔离级别。
所以隔离级别的作用是用来平衡数据库并发访问与数据一致性的方法。
事务的4种隔离级别
READ UNCOMMITTED 未提交读，可以读取未提交的数据。READ COMMITTED 已提交读，对于锁定读(select with for update 或者 for share)、update 和 delete 语句， InnoDB 仅锁定索引记录，而不锁定它们之间的间隙，因此允许在锁定的记录旁边自由插入新记录。 Gap locking 仅用于外键约束检查和重复键检查。REPEATABLE READ 可重复读，事务中的一致性读取读取的是事务第一次读取所建立的快照。SERIALIZABLE 序列化
在了解了 4 种隔离级别的需求后，在采用锁控制隔离级别的基础上，我们需要了解加锁的对象(数据本身&间隙)，以及了解整个数据范围的全集组成。
数据范围全集组成
SQL 语句根据条件判断不需要扫描的数据范围（不加锁）；
SQL 语句根据条件扫描到的可能需要加锁的数据范围；
以单个数据范围为例，数据范围全集包含：（数据范围不一定是连续的值，也可能是间隔的值组成）
1. 数据已经填充了整个数据范围：（被完全填充的数据范围，不存在数据间隙）
整形，对值具有唯一约束条件的数据范围 1～5 ，
已有数据1、2、3、4、5，此时数据范围已被完全填充；
整形，对值具有唯一约束条件的数据范围 1 和 5 ，
已有数据1、5，此时数据范围已被完全填充；
整形的数据范围 1～5 ，
已有数据 1、2、3、4、5，但是因为没有唯一约束，
所以数据范围可以继续被 1～5 的数据重复填充；
整形，具有唯一约束条件的数据范围 1～5 ，
已有数据 2，5，此时数据范围未被完全填充，还可以填充 1、3、4 ；
整形的数据范围 1～5 ，数据范围内当前没有任何数据。
更新丢失：当多个事务选择了同一行，然后基于最初选定的值更新该行时，
由于每个事物不知道其他事务的存在，最后的更新就会覆盖其他事务所做的更新；
脏读： 一个事务正在对一条记录做修改，这个事务完成并提交前，这条记录就处于不一致状态。
这时，另外一个事务也来读取同一条记录，如果不加控制，
第二个事务读取了这些“脏”数据，并据此做了进一步的处理，就会产生提交的数据依赖关系。
这种现象就叫“脏读”。
不可重复读：一个事务在读取某些数据后的某个时间，再次读取以前读过的数据，
却发现其读出的数据已经发生了改变，或者某些记录已经被删除了。
这种现象就叫“不可重复读”。
幻读：一个事务按相同的查询条件重新读取以前检索过的数据，
却发现其他事务插入了满足其查询条件的新数据，这种现象称为“幻读”。
可以简单的认为满足条件的数据量变化了。
Record Locks
索引记录锁，索引记录锁始终锁定索引记录，即使表中未定义索引，
这种情况下，InnoDB 创建一个隐藏的聚簇索引，并使用该索引进行记录锁定。
Gap Locks
间隙锁是索引记录之间的间隙上的锁，或者对第一条记录之前或者最后一条记录之后的锁。
间隙锁是性能和并发之间权衡的一部分。
对于无间隙的数据范围不需要间隙锁，因为没有间隙。
Next-Key Locks
索引记录上的记录锁和索引记录之前的 gap lock 的组合。
假设索引包含 10、11、13 和 20。
可能的next-key locks包括以下间隔，其中圆括号表示不包含间隔端点，方括号表示包含端点：
- (负无穷大, 10] (10, 11] (11, 13] (13, 20] (20, 正无穷大) 对于最后一个间隔，next-key将会锁定索引中最大值的上方，
2. 数据填充了部分数据范围：（未被完全填充的数据范围，是存在数据间隙）
3. 数据范围内没有任何数据（存在间隙）
如下：
在了解了数据全集的组成后，我们再来看看事务并发时，会带来的问题。
无控制的并发所带来的问题
并发事务如果不加以控制的话会带来一些问题，主要包括以下几种情况。
1. 范围内已有数据更改导致的：
2. 范围内数据量发生了变化导致：
因为无控制的并发会带来一系列的问题，这些问题会导致无法满足我们所需要的结果。因此我们需要控制并发，以实现我们所期望的结果(隔离级别)。
MySQL 隔离级别的实现
InnoDB 通过加锁的策略来支持这些隔离级别。
行锁包含：
左右滑动进行查看
"上确界"伪记录的值高于索引中任何实际值。
上确界不是一个真正的索引记录，因此，实际上，这个 next-key 只锁定最大索引值之后的间隙。
基于此，当获取的数据范围中，数据已填充了所有的数据范围，那么此时是不存在间隙的，也就不需要 gap lock。
对于数据范围内存在间隙的，需要根据隔离级别确认是否对间隙加锁。
默认的 REPEATABLE READ 隔离级别，为了保证可重复读，除了对数据本身加锁以外，还需要对数据间隙加锁。
READ COMMITTED 已提交读，不匹配行的记录锁在 MySQL 评估了 where 条件后释放。
对于 update 语句，InnoDB 执行 "semi-consistent" 读取，这样它会将最新提交的版本返回到 MySQL，
以便 MySQL 可以确定该行是否与 update 的 where 条件相匹配。
总结&延展：
唯一索引存在唯一约束，所以变更后的数据若违反了唯一约束的原则，则会失败。
当 where 条件使用二级索引筛选数据时，会对二级索引命中的条目和对应的聚簇索引都加锁；所以其他事务变更命中加锁的聚簇索引时，都会等待锁。
行锁的增加是一行一行增加的，所以可能导致并发情况下死锁的发生。
例如，
在 session A 对符合条件的某聚簇索引加锁时，可能 session B 已持有该聚簇索引的 Record Locks，而 session B 正在等待 session A 已持有的某聚簇索引的 Record Locks。
session A 和 session B 是通过两个不相干的二级索引定位到的聚簇索引。
session A 通过索引 idA，session B通过索引 idB 。
当 where 条件获取的数据无间隙时，无论隔离级别为 rc 或 rr，都不会存在间隙锁。
比如通过唯一索引获取到了已完全填充的数据范围，此时不需要间隙锁。
间隙锁的目的在于阻止数据插入间隙，所以无论是通过 insert 或 update 变更导致的间隙内数据的存在，都会被阻止。
rc 隔离级别模式下，查询和索引扫描将禁用 gap locking，此时 gap locking 仅用于外键约束检查和重复键检查（主要是唯一性检查）。
rr 模式下，为了防止幻读，会加上 Gap Locks。
事务中，SQL 开始则加锁，事务结束才释放锁。
就锁类型而言，应该有优化锁，锁升级等，例如rr模式未使用索引查询的情况下，是否可以直接升级为表锁。
就锁的应用场景而言，在回放场景中，如果确定事务可并发，则可以考虑不加锁，加快回放速度。
锁只是并发控制的一种粒度，只是一个很小的部分：
从不同场景下是否需要控制并发，(已知无交集且有序的数据的变更，MySQL 的 MTS 相同前置事务的多事务并发回放)
并发控制的粒度，(锁是一种逻辑粒度，可能还存在物理层和其他逻辑粒度或方式)
相同粒度下的优化，(锁本身存在优化，如IX、IS类型的优化锁)
粒度加载的安全&性能(如获取行锁前，先获取页锁，页锁在执行获取行锁操作后即释放，无论是否获取成功)等多个层次去思考并发这玩意。