MYSQL if 语句查询两个条件或任意一个条件都可以的

MYSQL if 语句查询两个条件或任意一个条件都可以的,第1张

应该这样写吧:

SELECT COUNT(*) FROM tougao_record WHERE accept_company_id=100 AND channel_type=1 AND check_status=6

MySQL数据库的认证密码有两种方式,

MySQL 4.1版本之前是MySQL323加密,MySQL 4.1和之后的版本都是MySQLSHA1加密,

MySQL数据库中自带Old_Password(str)和Password(str)函数,它们均可以在MySQL数据库里进行查询,前者是MySQL323加密,后者是MySQLSHA1方式加密。

(1)以MySQL323方式加密

select  old_password('111111')

(2)以MySQLSHA1方式加密

select password('111111')

 

MYSQL323加密中生成的是16位字符串,而在MySQLSHA1中生存的是41位字符串,其中*是不加入实际的密码运算中,通过观察在很多用户中都携带了"*",在实际破解过程中去掉"*",也就是说MySQLSHA1加密的密码的实际位数是40位。

使用 bitpoke的mysql-operator 作为k8s的mysql服务,使用的版本v0.4.0,

github地址:https://github.com/bitpoke/mysql-operator

MysqlCluster operator主要支持如下功能

建立的mysql服务每隔一段时间就重启,事件的报错信息如下

为什么心跳不通过?

貌似心跳机制不通过,查看pod信息

心跳默认20秒不通过,就重启,看源码也没有心跳配置项,坑啊,不过这只是表象,到底是什么导致心跳不通过?

mysqlCluster启动时,会启动4个容器metrices-exporter, mysql, pt-heartbeat, sidecar。看这4个容器的cpu, 内存使用情况,发现mysql内存超过,如下:

看最后状态,OOMKilled,而且当前内存使用率3.9G 接近limit 4G的设置。 找到产生的问题原因了,是因为内存超了,被容器杀掉,导致心跳不通过报错重启

为什么内存使用这么高?

思考mysql使用内存高,可能跟mysql自身缓存有关系,查内存相关参数

看到 innodb_buffer_pool_size 设置得值特别大,这个参数设置只有主要缓存innodb表的索引,数据,插入数据时的缓冲,但默认是8M。

为什么 innodb_buffer_pool_size 设置变得这么大?

翻翻mysqlCluster源码,跟innodb_buffer_pool_size 有关代码

default.go

问题就在这里,为了保证资源独占,mysql设置时是request = limit,因为自动计算导致 innodb-buffer-pool-size过大,最终导致oom,需要手动设置innodb-buffer-pool-size,就手动设置2G吧

设置 innodb-buffer-pool-size 不生效?

设置后,pod不重启? 参数没有生效设置。设另一个512M就生效了。尝试加入引号,作为字符串处理,配置开始生效。难道跟类型有关系? 继续看相关源码

default.go

看这个类型定义cluster.Spec.MysqlConf

MysqlClusterSpec

intstr

如果设置成数字,则整数是int32位

看int32位的长度

int32 the set of all signed 32-bit integers (-2147483648 to 2147483647)

至此内存使用过大的问题,解决了,内存使用也降下来了


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zaji/7648891.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-04-08
下一篇 2023-04-08

发表评论

登录后才能评论

评论列表(0条)

保存