备战实习,会定期的总结常考的面试题,大家一起加油! 🎯
往期文章:
参考文章:
https://blog.csdn.net/qq_45966440/category_11098049.html
https://csp1999.blog.csdn.net/article/details/116069114
https://joonwhee.blog.csdn.net/article/details/106893197
https://www.pdai.tech/md/db/sql-mysql/sql-mysql-overview.html
https://javaguide.cn/
注意:
如果本文中有错误的地方,欢迎评论区指正!🍭
文章目录

大体来说,MySQL可以分为Server层和存储引擎两部分:
Server 层
主要包括连接器、查询缓存、分析器、优化器、执行器等,所有跨存储引擎的功能都在这一层实现,比如存储过程、触发器、视图,函数等,还有一个通用的日志模块 binglog 日志模块。
存储引擎
主要负责数据的存储和读取,采用可以替换的插件式架构,支持 InnoDB、MyISAM、Memory 等多个存储引擎,其中 InnoDB 引擎有自有的日志模块 redolog 模块。现在最常用的存储引擎是 InnoDB,它从 MySQL 5.5.5 版本开始就被当做默认存储引擎了。
附:更加详细的功能可以参考 Server 层基本组件介绍
👩💻面试官追问:那你在说说MySQL查询的指令执行顺序?
编写顺序:
SELECT DISTINCT
<select list>
FROM
<left_table> <join_type>
JOIN
<right_table> ON <join_condition>
WHERE
<where_condition>
GROUP BY
<group_by_list>
HAVING
<having_condition>
ORDER BY
<order_by_condition>
LIMIT
<limit_params>
执行顺序:

大致可以分为四类:
TINYINT、SMALLINT、MEDIUMINT、INT、BIGINT分别占用8、16、24、32、64位存储空间。FLOAT、DOUBLE及DECIMAL为浮点数类。
CHAR和VARCHARyear、time、date、datetime、timestamp等👩💻面试官追问:详细说一下MySQL中char 和 varchar 的区别?
char∶固定长度类型,比如︰订阅char(10),当你输入"abc"三个字符的时候,它们占的空间还是10个字节,其他7个是空字节。
varchar︰可变长度,存储的值是=每个值占用的字节+一个用来记录其长度的字节的长度
从空间上考虑varchar比较合适。从效率上考虑char比较合适,二者使用需要权衡。
表格对比:
| 对比项 | char | varchar |
|---|---|---|
| 长度特点 | 长度固定,存储字符 | 长度可变,存储字符 |
| 长度不足情况 | 插入的长度小于定义长度时,则用空格填充 | 小于定义长度时,按实际插入长度存储 |
| 性能 | 存取速度比varchar快得多 | 存取速度比char慢得多 |
| 使用场景 | 适合存储很短的,固定长度的字符串,如手机号,MD5值等 | 适合用在长度不固定场景,如收货地址,邮箱地址等 |
👩💻面试官继续问:详细说一下MySQL中字段类型DATETIME 和 TIMESTA的区别?
| 类型 | 占据字节 | 范围 | 时区问题 |
|---|---|---|---|
| datetime | 8 字节 | 1000-01-01 00:00:00到 9999-12-31 23:59:59 | 存储与时区无关,不会发生改变 |
| timestamp | 4 字节 | 1970-01-01 00:00:01 到 2038-01-19 11:14:07 | 存储的是与时区有关,随数据库的时区而发生改变 |
应该尽量使用timestamp,相比于datetime它有着更高的空间效率
| 对比 | InnoDB | MyISAM |
|---|---|---|
| 事务 | 支持 | 不支持 |
| 锁类型 | 行锁、表锁 | 表锁 |
| MVCC | 支持 | 不支持 |
| 外键 | 支持 | 不支持 |
| 索引 | 聚簇索引、5.7以后支持全文索引 | 非聚簇索引、支持全文索引 |
| 安全性 | 支持数据库异常崩溃后的安全恢复 | 不支持 |
| 缓存 | 仅缓存索引,还缓存真实数据,对内存要求较高 | 只缓存索引,不缓存真实数据 |
| 备份 | InnoDB 支持在线热备份 | 不支持 |
👩💻面试官追问:平时选择存储引擎的时候这两个怎么取舍?
InnoDB
是Mysql的默认存储引擎,用于事务处理应用程序,支持外键。如果应用对事务的完整性有比较高的要求,在并发条件下要求数据的一致性,数据操作除了插入和查询意外,还包含很多的更新、删除操作,那么InnoDB存储引擎是比较合适的选择。对于类似于计费系统或者财务系统等对数据准确性要求比较高的系统,InnoDB是最合适的选择。
MyISAM
如果应用是以读操作和插入操作为主,只有很少的更新和删除操作,并且对事务的完整性、并发性要求不是很高,那么选择MyISAM存储引擎是非常合适的
Buffer Pool 是 InnoDB 维护的一个缓存区域,用来缓存数据和索引在内存中,主要用来加速数据的读写,如果 Buffer Pool 越大,那么 MySQL 就越像一个内存数据库,默认大小为 128M。
索引是一种用于快速查询和检索数据的数据结构。常见的索引结构有: B 树, B+树和 Hash。
索引的作用就相当于目录的作用。打个比方:我们在查字典的时候,如果没有目录,那我们就只能一页一页的去找我们需要查的那个字,速度很慢。如果有目录了,我们只需要先去目录里查找字的位置,然后直接翻到那一页就行了。
👩💻面试官追问:说说索引的优缺点?
优点 :
缺点 :
👩💻面试官继续问:说说哪些情况适合建立索引哪些不适合?
适合建立索引:
不适合建立索引的情况:
主键索引
数据表的主键列使用的就是主键索引。一张数据表有只能有一个主键,并且主键不能为 null,不能重复。
唯一索引(Unique Key)
唯一索引也是一种约束。唯一索引的属性列不能出现重复的数据,但是允许数据为 NULL,一张表允许创建多个唯一索引。 建立唯一索引的目的大部分时候都是为了该属性列的数据的唯一性,而不是为了查询效率。
普通索引(Index)
普通索引的唯一作用就是为了快速查询数据,一张表允许创建多个普通索引,并允许数据重复和 NULL。
前缀索引(Prefix)
前缀索引只适用于字符串类型的数据。前缀索引是对文本的前几个字符创建索引,相比普通索引建立的数据更小, 因为只取前几个字符。
全文索引(Full Text)
全文索引主要是为了检索大文本数据中的关键字的信息,是目前搜索引擎数据库使用的一种技术。(Mysql5.6 之前只有 MYISAM 引擎支持全文索引,5.6 之后 InnoDB 也支持了全文索引)
其中唯一索引、普通索引、前缀索引、全文索引又称为二级索引(辅助索引)
InnoDB、MyISAM、Memory三种存储引擎对各种索引类型的支持:
| 索引 | InnoDB引擎 | MyISAM引擎 | Memory引擎 |
|---|---|---|---|
| B+Tree 索引 | 支持 | 支持 | 支持 |
| 哈希索引 | 不支持 | 不支持 | 支持 |
| 空间数据索引 | 不支持 | 支持 | 不支持 |
| 全文索引 | 5.6版本之后支持 | 支持 | 不支持 |

👩💻面试官追问:那你说说B 树和B+树两者有何异同呢?
B树结构图:

可以看出:
👩💻面试官追问:为什么MySQL数据库要用B+树存储索引?而不用红黑树、Hash、B树?
红黑树
如果在内存中,红黑树的查找效率比B树更高,但是涉及到磁盘操作,B树就更优了。因为红黑树是二叉树,数据量大时树的层数很高,从树的根结点向下寻找的过程,每读1个节点,都相当于一次IO操作,因此红黑树的I/O操作会比B树多的多。
hash 索引
如果只查询单个值的话,hash 索引的效率非常高。但是 hash 索引有几个问题:①不支持范围查询 ②不支持索引值的排序操作 ③不支持联合索引的最左匹配规则。
B树索引
👩💻面试官继续追问:B+树中一个节点到底多大合适?
1页或页的倍数最为合适。因为如果一个节点的大小小于1页,那么读取这个节点的时候其实也会读出1页,造成资源的浪费。所以为了不造成浪费,所以最后把一个节点的大小控制在1页、2页、3页等倍数页大小最为合适。
这里说的“页”是 MySQL 自定义的单位(和操作系统类似),MySQL 的 Innodb 引擎中1页的默认大小是16k,可以使用命令SHOW GLOBAL STATUS LIKE 'Innodb_page_size' 查看。

聚集索引:即索引结构和数据一起存放的索引。主键索引属于聚集索引
在 Mysql 中,InnoDB 引擎的表的
.ibd文件就包含了该表的索引和数据,对于 InnoDB 引擎表来说,该表的索引(B+树)的每个非叶子节点存储索引,叶子节点存储索引和索引对应的数据
非聚集索引:即索引结构和数据分开存放的索引。二级索引属于非聚集索引
MYISAM 引擎的表的
.MYI文件包含了表的索引, 该表的索引(B+树)的每个非叶子节点存储索引, 叶子节点存储索引和索引对应数据的指针,指向.MYD文件的数据。
如图:

如上图,主键索引的叶子节点保存的是真正的数据。而辅助索引叶子节点的数据区保存的是主键索引关键字的值
假如要查询name = C 的数据,其搜索过程如下:
之所以这样设计,一个原因就是:如果和MyISAM一样在主键索引和辅助索引的叶子节点中都存放数据行指针,一旦数据发生迁移,则需要去重新组织维护所有的索引
👩💻面试官追问:聚集索引的优缺点有哪些?
聚集索引的查询速度非常的快,因为整个B+树本身就是一颗多叉平衡树,叶子节点也都是有序的,定位到索引的节点,就相当于定位到了数据。
聚集索引的缺点
依赖于有序的数据
因为 B+树是多路平衡树,如果索引的数据不是有序的,那么就需要在插入时排序,如果数据是整型还好,否则类似于字符串或 UUID 这种又长又难比较的数据,插入或查找的速度肯定比较慢
更新代价大
如果对索引列的数据被修改时,那么对应的索引也将会被修改, 而且聚集索引的叶子节点还存放着数据,修改代价肯定是较大的, 所以对于主键索引来说,主键一般都是不可被修改的
👩💻面试继续问:非聚集索引的优缺点有哪些?
非聚集索引的优点
更新代价比聚集索引要小 。非聚集索引的更新代价就没有聚集索引那么大了,非聚集索引的叶子节点是不存放数据的
非聚集索引的缺点
👩💻面试继续追问:非聚集索引一定回表查询吗?
不一定,原因详细看下面第6问
覆盖索引:指的是在一次查询中,如果一个索引包含或者说覆盖所有需要查询的字段的值,我们就称之为覆盖索引,而不再需要回表查询
覆盖索引即需要查询的字段正好是索引的字段,那么直接根据该索引,就可以查到数据了, 而无需回表查询。
举个栗子:

事务是用户定义的一个数据库操作序列,这些操作要么全不做,要么全做,是一个不可分割的工作单位。
举个栗子:就拿最经典的转账例子来说,假如小明要给小红转账1000元,这个转账会涉及到两个关键操作就是:将小明的余额减少1000元,将小红的余额增加1000元。万一在这两个操作之间突然出现错误比如银行系统崩溃,导致小明余额减少而小红的余额没有增加,这样就不对了。事务就是保证这两个关键操作要么都成功,要么都要失败。

原子性(Atomicity)
事务是最小的执行单位,不允许分割。事务的原子性确保事务所有的操作要么全部提交成功,要么全部失败回滚。
一致性(Consistency)
执行事务前后,数据保持一致,例如转账业务中,无论事务是否成功,转账者和收款人的总额应该是不变的。
隔离性(Isolation)
并发访问数据库时,一个用户的事务不被其他事务所干扰,各并发事务之间数据库是独立的。
持久性(Durability)
一个事务一旦提交,它对数据库中数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其执行结果有任何影响。
脏读(Dirty read)
当一个事务正在访问数据并且对数据进行了修改,而这种修改还没有提交到数据库中,这时另外一个事务也访问了这个数据,然后使用了这个数据。因为这个数据是还没有提交的数据,那么另外一个事务读到的这个数据可能就是“脏数据”,这就是脏读。
丢失修改(Lost to modify)
两个事务T1和T2读入同一数据并修改。T2提交的结果破坏了T1提交的结果,导致T1的修改被丢失。
不可重复读(Unrepeatableread)
事务T1读取某一数据后,事务T2对其进行了修改,当事务T1再次读该数据时,得到与前一次不同的值。因此称为不可重复读。
幻读(Phantom read)
和不可重复读很类似:
事务T1按一定条件从数据库中读取某些数据记录后,事务T2删除了其中部分记录,当T1再次按相同条件读取数据时,发现某些记录神秘消失了。
事务T1按一定条件从数据库中读取某些数据记录后,事务T2插入一些记录,当T1再次按相同条件读取数据时,发现多了一些记录。
SQL 标准定义了四个隔离级别:
读未提交(Read Uncommitted)
最低的隔离级别,允许读取尚未提交的数据变更,可能会导致脏读、幻读或不可重复读。
读已提交(Read Committed)
允许读取并发事务已经提交的数据,可以阻止脏读,但是幻读或不可重复读仍有可能发生。
可重复读(Repeatable Read)
对同一字段的多次读取结果都是一致的,除非数据是被本身事务自己所修改,可以阻止脏读和不可重复读,但幻读仍有可能发生。
可串行化(Serializable)
最高的隔离级别,完全服从ACID的隔离级别。所有的事务依次逐个执行,这样事务之间就完全不可能产生干扰,也就是说,该级别可以防止脏读、不可重复读以及幻读。
总结一张表:
| 隔离级别 | 脏读 | 不可重复读 | 幻读 |
|---|---|---|---|
| 读未提交(Read Uncommitted) | √ | √ | √ |
| 读已提交(Read Committed) | × | √ | √ |
| 可重复读(Repeatable Read) | × | × | √ |
| 可串行化(Serializable) | × | × | × |
👩💻面试官追问:MySQL的默认隔离级别是什么?
MySQL InnoDB 存储引擎的默认支持的隔离级别是 REPEATABLE-READ(可重读)。我们可以通过SELECT @@tx_isolation;命令来查看,MySQL 8.0 该命令改为SELECT @@transaction_isolation;

可以从几个方面考虑:
优化表结构
尽量使用数字型字段。若只含数值信息的字段尽量不要设计为字符型,这会降低查询和连接的性能,并会增加存储开销。这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符,而对于数字型而言只需要比较一次就够了。
尽可能的使用 varchar 代替 char。可变长字段存储空间小,可以节省存储空间。
当索引列大量重复数据时,可以把索引删除掉。比如有一列是性别,只有男、女,这样的索引是无效的。
优化查询
!= 或 <> 操作符,否则将引擎放弃使用索引而进行全表扫描。or 来连接条件,如果一个字段有索引,一个字段没有索引,将导致引擎放弃使用索引而进行全表扫描。建议使用 union 替换 ornull 值判断,否则将导致引擎放弃使用索引而进行全表扫描in 和 not in 也要慎用,否则会导致全表扫描JOIN)select *!索引优化
order by的字段建立索引where 及 order by 涉及的列上建立索引其他优化
当进行数据的insert操作的时候,可以考虑采用以下几种优化方案:
附:更多详细的优化sql操作可以参考SQL优化
最左前缀原则,就是最左优先,在创建多列索引时,要根据业务需求,where 子句中使用最频繁的一列放在最左边。
当我们创建一个组合索引的时候,如 (a1,a2,a3),相当于创建了(a1)、(a1,a2)和(a1,a2,a3)三个索引,这就是最左匹配原则。
详细explain的文章可以参考:MySQL高级详解
在 select 语句之前增加 explain 关键字,会返回执行计划的信息。
各个字段含义:
| 字段 | 含义 |
|---|---|
| id | select查询的序列号,是一组数字,表示的是查询中执行select子句或者是操作表的顺序。 |
| select_type | 表示 SELECT 的类型,常见的取值有 SIMPLE(简单表,即不使用表连接或者子查询)、PRIMARY(主查询,即外层的查询)、UNION(UNION 中的第二个或者后面的查询语句)等 |
| table | 展示这一行的数据是关于哪一张表的 |
| type | 表示表的连接类型,性能由好到差的连接类型为:system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL |
| possible_keys | 表示查询时,可能使用的索引 |
| key | 表示实际使用的索引 |
| key_len | 索引字段的长度 |
| rows | 这一列是 mysql 估计要读取并检测的行数,注意这个不是结果集里的行数 |
| extra | 其他额外的执行计划信息。比如有 Using index、Using where、Using temporary等 |
答案→优化篇-1-优化查询
主从复制主要涉及三个线程:binlog 线程、I/O 线程和 SQL 线程
Binary log)中Relay log)
主从复制具体过程分成三步:
假如一个服务器开放N个连接给客户端,这样有会有大并发的更新操作,但是从服务器的里面读取 binlog 的SQL线程仅有一个,导致从库SQL可能会跟不上主库的处理速度。
👩💻面试官追问:主从同步出现延迟的解决办法?

可以使用半同步复制或全同步复制。
半同步复制
主库修改语句写入binlog后,不会立即给客户端返回结果。而是首先通过log dump 线程将 binlog 发送给从库,从库的 I/O 线程收到 binlog 后,写入到 relay log,然后返回 ACK 给主库,主库收到 ACK 后,再返回给客户端成功
全同步复制
主库写入binlog后强制同步日志到从库,所有的从库都执行完成后才返回给客户端,但是很显然这个方式的话性能会受到严重影响
读写分离常用代理方式来实现,代理服务器接收应用层传来的读写请求,然后决定转发到哪个服务器。主服务器处理写操作以及实时性要求比较高的读操作,而从服务器处理读操作。
👩💻面试官追问:读写分离为什么能够提高性能?
MyISAM,提升查询性能以及节约系统开销
show engine innodb status;乐观锁
认为对于同一个数据的并发操作,是不会发生修改的。在更新数据的时候,会采用不断尝试更新的方式来修改数据。也就是先不管资源有没有被别的线程占用,直接申请操作,如果没有产生冲突,那就操作成功,如果产生冲突,说明有其他线程已经在使用了,然后在不断地尝试。
乐观锁实现方式:一般通过版本号和CAS算法实现。
悲观锁
认为对于同一个数据的并发操作,一定是会发生修改的,哪怕没有修改,也会认为修改。因此对于同一个数据的并发操作,悲观锁采取加锁的形式。悲观的认为,不加锁的并发操作一定会出问题。
悲观锁的实现方式:使用共享锁和排它锁,select...lock in share mode,select…for update。
表级锁
MySQL 中锁定粒度最大的一种锁,对当前操作的整张表加锁,实现简单,资源消耗也比较少,加锁快,不会出现死锁。其锁定粒度最大,触发锁冲突的概率最高,并发度最低,MyISAM 和 InnoDB 引擎都支持表级锁。
行级锁
MySQL 中锁定粒度最小的一种锁,只针对当前操作的行进行加锁。 行级锁能大大减少数据库操作的冲突。其加锁粒度最小,并发度高,但加锁的开销也最大,加锁慢,会出现死锁。 InnoDB 引擎都支持表级锁,MyISAM不支持。
👩💻面试官追问:InnoDB 的行锁是怎么实现的?
InnoDB 行锁是通过索引上的索引项来实现的。意味者,只有通过索引条件检索数据,InnoDB 才会使用行级锁,否则,InnoDB将使用表锁!
👩💻面试官继续追问:InnoDB 锁的算法有哪几种?
一共三种:
Record lock:记录锁(行锁),单条索引记录上加锁,锁住的永远是索引,而非记录本身。Gap lock:间隙锁,在索引记录之间的间隙中加锁,或者是在某一条索引记录之前或者之后加锁,并不包括该索引记录本身。Next-key lock:临键锁,Record lock 和 Gap lock 的结合,即除了锁住记录本身,也锁住索引之间的间隙。关于三种锁详细的讲解可以参考:MySQL如何解决幻读和不可重复度?
共享锁
又称为读锁,简称S锁,顾名思义,共享锁就是多个事务对于同一数据可以共享一把锁,都能访问到数据,但是只能读不能修改。一个事务获取了共享锁,其他事务可以再加共享锁,但是不能加排他锁。
排他锁
又称为写锁,简称X锁,顾名思义,排他锁就是不能与其他锁并存,如一个事务获取了一个数据行的排他锁,其他事务就不能再获取该行的其他锁,包括共享锁和排他锁,但是获取排他锁的事务可以对数据行读取和修改。

最后喜欢的小伙伴,记得三联哦!😏🍭😘
文章目录一、概述简介原理模块二、配置Mysql使用版本环境要求1.操作系统2.mysql要求三、配置canal-server离线下载在线下载上传解压修改配置单机配置集群配置分库分表配置1.修改全局配置2.实例配置垂直分库水平分库3.修改group-instance.xml4.启动监听四、配置canal-adapter1修改启动配置2配置映射文件3启动ES数据同步查询所有订阅同步数据同步开关启动4.验证五、配置canal-admin一、概述简介canal是Alibaba旗下的一款开源项目,Java开发。基于数据库增量日志解析,提供增量数据订阅&消费。Git地址:https://github.co
HashMap中为什么引入红黑树,而不是AVL树呢1.概述开始学习这个知识点之前我们需要知道,在JDK1.8以及之前,针对HashMap有什么不同。JDK1.7的时候,HashMap的底层实现是数组+链表JDK1.8的时候,HashMap的底层实现是数组+链表+红黑树我们要思考一个问题,为什么要从链表转为红黑树呢。首先先让我们了解下链表有什么不好???2.链表上述的截图其实就是链表的结构,我们来看下链表的增删改查的时间复杂度增:因为链表不是线性结构,所以每次添加的时候,只需要移动一个节点,所以可以理解为复杂度是N(1)删:算法时间复杂度跟增保持一致查:既然是非线性结构,所以查询某一个节点的时候
目录第1题连续问题分析:解法:第2题分组问题分析:解法:第3题间隔连续问题分析:解法:第4题打折日期交叉问题分析:解法:第5题同时在线问题分析:解法:第1题连续问题如下数据为蚂蚁森林中用户领取的减少碳排放量iddtlowcarbon10012021-12-1212310022021-12-124510012021-12-134310012021-12-134510012021-12-132310022021-12-144510012021-12-1423010022021-12-154510012021-12-1523.......找出连续3天及以上减少碳排放量在100以上的用户分析:遇到这类
我看到其他人也遇到过类似的问题,但没有一个解决方案对我有用。0.3.14gem与其他gem文件一起存在。我已经完全按照此处指示完成了所有操作:https://github.com/brianmario/mysql2.我仍然得到以下信息。我不知道为什么安装程序指示它找不到include目录,因为我已经检查过它存在。thread.h文件存在,但不在ruby目录中。相反,它在这里:C:\RailsInstaller\DevKit\lib\perl5\5.8\msys\CORE\我正在运行Windows7并尝试在Aptana3中构建我的Rails项目。我的Ruby是1.9.3。$gemin
我已经开始使用mysql2gem。我试图弄清楚一些基本的事情——其中之一是如何明确地执行事务(对于批处理操作,比如多个INSERT/UPDATE查询)。在旧的ruby-mysql中,这是我的方法:client=Mysql.real_connect(...)inserts=["INSERTINTO...","UPDATE..WHEREid=..",#etc]client.autocommit(false)inserts.eachdo|ins|beginclient.query(ins)rescue#handleerrorsorabortentirelyendendclient.commi
我正在尝试绕过rails配置这个极其复杂的迷宫。到目前为止,我设法在ubuntu上设置了rvm(出于某种原因,ruby在ubuntu存储库中已经过时了)。我设法建立了一个Rails项目。我希望我的测试项目使用mysql而不是mysqlite。当我尝试“rakedb:migrate”时,出现错误:“!!!缺少mysql2gem。将其添加到您的Gemfile:gem'mysql2'”当我尝试“geminstallmysql”时,出现错误,告诉我需要为安装命令提供参数。但是,参数列表很大,我不知道该选择哪些。如何通过在ubuntu上运行的rvm和mysql获取rails3?谢谢。
我正在使用RABL输出Sunspot/SOLR结果集,搜索结果对象由多种模型类型组成。目前在rablView中我有:objectfalsechild@search.results=>:resultsdoattribute:id,:resource,:upccodeattribute:display_description=>:descriptioncode:start_datedo|r|r.utc_start_date.to_iendcode:end_datedo|r|r.utc_end_date.to_iendendchild@search=>:statsdoattribute:to
?作者主页:静Yu?简介:CSDN全栈优质创作者、华为云享专家、阿里云社区博客专家,前端知识交流社区创建者?社区地址:前端知识交流社区?博主的个人博客:静Yu的个人博客?博主的个人笔记本:前端面试题个人笔记本只记录前端领域的面试题目,项目总结,面试技巧等等。接下来会更新蓝桥杯官方系统基础练习的VIP试题,依然包括解题思路,源代码等等。问题描述:给定当前的时间,请用英文的读法将它读出来。时间用时h和分m表示,在英文的读法中,读一个时间的方法是: 如果m为0,则将时读出来,然后加上“o’clock”,如3:00读作“threeo’clock”。 如果m不为0,则将时读出来,然后将分读出来,如5
目录1、yum安装mysql修改密码(1)在mysql里面修改(2)第二种方式,利用mysqladmin修改密码2、没有密码,登录mysql修改密码3、mysql的安全设置1、yum安装mysql在CentOS中默认安装有MariaDB(MySQL的一个分支),安装完成之后可以直接覆盖MariaDB。rpm-qa|grepmariadb查询是否安装了mariadbrpm-e--nodepsmariadb-libs-5.5.60-1.el7_5.x86_64卸载mariadwgethttp://dev.mysql.com/get/mysql57-community-release-el7-11.
我是Ruby的新手。我安装了DataMapper并且正在尝试安装dm-mysql-adapter-1.0.2gem。但是当我尝试安装时,出现以下错误。我正在使用ubuntu操作系统。vinoth@vinoth-laptop:~/Downloads$geminstalldm-mysql-adapter-1.0.2----with-mysql-lib=/usr/lib/mysql----with-mysql-conf=/usr/bin/mysqlWARNING:Installingto~/.gemsince/home/vinoth/gemsand/home/vinoth/gems/bina