mysql客户端踩坑

mysql -uroot -p123456 -P3308

mysql -uroot -p123456 -P3308 -h127.0.0.1

这2中链接方式有区别吗?

strace  mysql -uroot -p123456 -P3308 得到如下结果

stat("/etc/my.cnf", 0x7fff2b1fe5a0) = -1 ENOENT (No such file or directory)
stat("/etc/mysql/my.cnf", 0x7fff2b1fe5a0) = -1 ENOENT (No such file or directory)
stat("/home/work/mysql/etc/my.cnf", {st_mode=S_IFREG|0644, st_size=20538, ...}) = 0
open("/home/work/mysql/etc/my.cnf", O_RDONLY) = 3

表示-h -P 参数没有一起使用的话,-P参数相当于没写

mysql -uroot -p123456 -P3308 -h127.0.0.1 才是真正的连接3308端口

时间: 2024-10-18 13:27:17

mysql客户端踩坑的相关文章

记录一下安装 mysql 的踩坑之路

坑点: 1.旧的mysql没有删除干净.在安装mysql的时候,没有注意到,在输入 "mysqld install" 指令时跳出来 exits,存在于另一个文件夹之中,这影响了后来的很多操作,包括root之后修改密码,但是一直显示密码不对,在网上搜的时候有一位朋友也遇到了同样的问题:    2.ini文件的配置,参考http://www.runoob.com/mysql/mysql-install.html,我还是在ini文件里配置了databases,如果要手动配置的话,一定要新建一

Linux下部署MySQL,大小写敏感踩坑记录

今天在将开发环境中的门户数据库复制到新环境后,使用SqlSugar的ORM框架进行数据库操作的时候,出现了主键找不到的现象.排查了很久终于发现了关键点.特此记录. 1.开发环境:    操作系统:CENTOS7 64位    内存:    1GB    CPU     1/1    网络适配器:网桥模式    安装模式:最小化安装    系统语言设置:zh_CN.gb2312        数据库版本:MySQL 5.6.29 binary 模式安装    建立数据库之前:my.cnf参数配置 

[踩坑] MySQL max_allowed_packet导致sql文件source异常问题

踩坑: 今天通过mysqldump导出数据,在目标机器上开个screen执行source导入数据.过一会看了下,发现居然导入报错了.报错提示如下: 刚开始还以为是sql_mode设置的问题,改了sql_mode为宽松模式,再次导入还是报错. 网上查了下,http://blog.goyiyo.com/archives/1535 set global max_allowed_packet=524288000;    设置为512MB 退出mysql,然后再登进去source即可. 究其原因,是因为之

Spark踩坑记——数据库(Hbase+Mysql)转

转自:http://www.cnblogs.com/xlturing/p/spark.html 前言 在使用Spark Streaming的过程中对于计算产生结果的进行持久化时,我们往往需要操作数据库,去统计或者改变一些值.最近一个实时消费者处理任务,在使用spark streaming进行实时的数据流处理时,我需要将计算好的数据更新到hbase和mysql中,所以本文对spark操作hbase和mysql的内容进行总结,并且对自己踩到的一些坑进行记录. Spark Streaming持久化设计

Ubuntu 16.04 安装Mysql 5.7 踩坑小记

title:Ubuntu 16.04 安装Mysql 5.7 踩坑小记 date: 2018.02.03 安装mysql sudo apt-get install mysql-server mysql-client 测试是否安装成功 sudo netstat -tap | grep mysql 相关操作 登录 mysql -uroot -p 检查MySQL服务器占用端口 netstat -nlt|grep 3306 检查MySQL服务器系统进程 ps -aux|grep mysql 查看数据库的

[转]Spark 踩坑记:数据库(Hbase+Mysql)

https://cloud.tencent.com/developer/article/1004820 Spark 踩坑记:数据库(Hbase+Mysql) 前言 在使用Spark Streaming的过程中对于计算产生结果的进行持久化时,我们往往需要操作数据库,去统计或者改变一些值. 最近一个实时消费者处理任务,在使用spark streaming进行实时的数据流处理时,我需要将计算好的数据更新到hbase和mysql中,所以本文对spark操作hbase和mysql的内容进行总结,并且对自己

MySQL 已有大数据量表进行分区踩坑

一.背景mysql 表中已有 4 亿数据,为提高查询效率,需创建分区,一开始计划是创建 HASH 分区,结果报错:ERROR 1659 (HY000): Field 'partno' is of a not allowed type for this type of partitioning1 查询得知报错原因,HASH 分区只支持数字分区,而我要分区的字段是 varchar 类型,故改用 KEY 分区二.解决 KEY 分区语句: alter table TABLENAME PARTITION

阿里云磁盘扩容踩坑总结

公司半年前上线一个新的项目,采购了一批阿里云主机,磁盘组成是40G系统盘+100G的数据盘,数据库采用MariaDB Galera Cluster集群部署,由于业务数据量快速增长,导致磁盘存储空间剩余量很少,急需要扩容,先总结整个项目规划中埋下的坑: 1.没有DBA对数据库的容量规划,而前期的运维人员采购时选用100G的SSD云盘: 2.数据库默认使用共享表空间,缺点是删除数据后不释放空间,当数据快速增长后,我们采取了先删除临时表数据的方式来尽量避免暴力扩容,争取在春节期间稳定,删除部分数据后,

TiDB 深度实践之旅--真实“踩坑”经历

美团点评 TiDB 深度实践之旅(9000 字长文 / 真实“踩坑”经历) 4 PingCAP · 154 天前 · 3956 次点击 这是一个创建于 154 天前的主题,其中的信息可能已经有所发展或是发生改变. 原标题:美团点评携手 PingCAP 开启新一代数据库深度实践之旅 一.背景和现状 在美团,基于 MySQL 构建的传统关系型数据库服务已经难于支撑公司业务的爆发式增长,促使我们去探索更合理的数据存储方案和实践新的运维方式.随着近一两年来分布式数据库大放异彩,美团 DBA 团队联合架构