I never had much reason to use table compression, so I largely ignored the topic in MySQL. I knew that MySQL had table compression since 5.1, but I also knew the implementation was horribly complicated and double stored all data. There is also page compression, a feature introduced with 5.7, which replaces table compression and works much better.

Table Compression

Table Compression is available in MySQL 5.1 and newer. It is used by setting an InnoDB table up with ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8 or similar, for even smaller key block sizes. A lot of status tables in INFORMATION_SCHEMA.%CMP% are available to monitor it.

Table compression creates smaller pages (in the size you specify with KEY_BLOCK_SIZE), and loads and stores compressed pages of this smaller size from and to the …

We observe a large number of messages of the kind

The table '../tmp/#sql…' is full

Before MySQL 8

In older Versions of MySQL, implied temporary tables are being created whenever your EXPLAIN contained the phrase using temporary.

In this case, MySQL would create an in-memory temporary table to materialize an intermediate query result, and then continue to process the data from there. If that temporary table was larger than some configurable limit, the temporary table would instead be converted to a MyISAM table on disk, streamed out, and then work would continue with this.

This has a large number of disadvantages:

• A table in the MEMORY storage engine can have no variable length columns. That means, any VARCHAR column gets converted to …

We observe a large number of messages of the kind

The table '../tmp/#sql…' is full

Before MySQL 8

In older Versions of MySQL, implied temporary tables are being created, whenever your EXPLAIN contained the phrase using temporary.

In this case, MySQL would create an in-memory temporary table to materialize an intermediate query result, and then continue to process the data from there. If that temporary table was larger than some configurable limit, the temporary table would instead be converted to a MyISAM table on disk, streamed out, and then work would continue with this.

This has a large number of disadvantages:

• A table in the MEMORY storage engine can have no variable length columns. That means, any VARCHAR column gets converted to a CHAR column in the MEMORY version of that table.
  …

Setup for SSL MySQL Enterprise Database Version 8.0.22

Purpose of the Document

Procedure for MySQL Database Installation ( 8.0.22 – Enterprise) and setup for SSL on RHEL 8

=====================================================================

MySQL Database Installation –RHEL 8.x – DB Version 8.0.22 – Enterprise Edition

=====================================================================

The below procedure is related to MySQL Database Installation Version 8.0.22 on RHEL 8.4. ( Enterprise Edition)

MySQL Server 172.31.17.141

MySQL Client 172.31.25.170

(1) Check the OS version of RHEL by using below command.

[root@mysql-server ~]# cat /etc/redhat-release

Red Hat Enterprise Linux release 8.4 (Ootpa)

(2) Create local group for dba

[root@mysql-server ~]# groupadd -g 1020 dba

(3) Create local user for mysql

…

This blog post is inspired by Jesper's recent blog post on how the automatic update of InnoDB persistent statistics may never trigger if servers are restarted frequently. However, the matter is even worse! In this blog post I will show that even when the automatic recalculation is performed, there are no guarantees as to when the server will see the changes.

Myths about persistent statistics

I must admit that I, for a long time, believed in the myths I was told about when updates to InnoDB's index statistics become visible to the query optimizer. There were basically two variants:

• The updated statistics will only be visible to new connections (i.e., sessions that are started after the statistics was updated)
• When a new connection accesses the table, the updated statistics …

I’m studying and beginning to use CodeIgniter 4 in ‘real-world‘ projects and want to share what I learn, as I pick up on concepts of the framework. I’m posting a series of CRUD-related posts over on Medium and resharing them here for any readers who are interested…

Are you a Medium member? If so, receive an email notification each time I publish a blog post if you prefer the Medium platform. Not a member? No worries! Use my sign-up link (I will get a commission at no extra cost to you) and join. I really enjoy reading all the great content there and I know you will too!!!

…

MySQL, the world’s most popular open source database, is available as a managed cloud service in Oracle Cloud Infrastructure (OCI) under the name of MySQL Database Service (MDS).

This is the sixth episode of “Discovering MySQL Database Service“, a series of tutorials where I will show you, step by step, how to use MySQL Database Service and some other Oracle Cloud Infrastructure services.

In this episode, we’ll introduce the concept of Security Lists a virtual firewall to control traffic at the network packet level.

The post Discovering MySQL Database Service – Episode 6 – Update the Private Subnet Security List first appeared on dasini.net - Diary of a MySQL expert.

We already saw how easy it’s to deploy solutions on OCI using Terraform and Resource Manager’s Stack. I’ve published several resources available on this page.

Today we will see how easy it’s to deploy Apache Superset on OCI using MySQL Data Service.

Apache Superset is an open source BI, Reporting, Charting tool that competes with Tableau, Looker, etc.  For a list of companies that have deployed Superset, see:  https://github.com/apache/superset/blob/master/RESOURCES/INTHEWILD.md.

Superset is loaded with options that make it easy for users of all skill sets to explore and visualize their data, from simple line charts to highly detailed geospatial charts.

For a gallery of …

Originally posted at Andres's blog. Traditional query optimizing is mostly about two things: first, in which order and from where to access data, and then how to then combine it. You have probably seen the tree shapes execution plans that are produced from query planning. I’ll use an example from the MySQL docs, using FORMAT=TREE which was introduced in MySQL 8.0: mysql>EXPLAINFORMAT=TREE->SELECT*->FROMt1->JOINt2->ON(t1.c1=t2.c1ANDt1.c2<t2.c2)->JOINt3->ON(t2.c1=t3.c1)\G***************************1.row***************************EXPLAIN:->Innerhashjoin(t3.c1=t1.c1)(cost=1.05rows=1)->Tablescanont3(cost=0.35rows=1)->Hash->Filter:(t1.c2<t2.c2)(cost=0.70rows=1)->Innerhashjoin(t2.c1=t1.c1)(cost=0.70rows=1)->Tablescanont2(cost=0.35rows=1)->Hash->Tablescanont1(cost=0.35rows=1)Here we can see that the MySQL optimizer thinks the best plan is to start reading from t1 using a table scan.

Since we just released Galera Manager, it seemed like a good idea to do a deployment on Amazon Web Services (AWS) using Red Hat Enterprise Linux 8 and MySQL 8.

We start by launching an EC2 instance and choosing Red Hat Enterprise Linux 8 (HVM) and most importantly, we only choose the 64-bit (x86) architecture as we do not support ARM just yet. We choose a t2.micro instance for Galera Manager since this is just a test instance, but it is well worth knowing that 10GB which is the default EBS size may be a little small if you plan on using this for sometime.

…