This is the video from LaraconEU 2016 on Making the Most out of MySQL.
This is a blogpost about MySQL 8.0.0, the content here could be subject to changes in the future since this is not a stable release.
This is a feature that will make life the many DevOps and DBAs easier. Believe it or not, a lot of people control access to the database by sharing the same username and password. Which is completely insecure for a number of reasons:
- If someone is fired, they still have access
- If you get hacked for using the same password, well, I only can say: good luck
That also means: no more querying to Stack Overflow to get that
GRANT statement for each user you need to
create. (Thank you @mwop for reminding me of this).
Creating a Role
This is a group of privileges that will be assigned to users:
CREATE ROLE …[Read more]
This is an unstable release, please don’t use in production.
It was rumored that the new MySQL version would be 8 and not as 5.8 as a lot of people thought, and it appears the rumors were true.
Below are some of the features that caught my eye at first glance:
Although password expiration was implemented 5.7, the newer
version bring a set of collective privileges as a
Role. No need to have to copy paste that massive
GRANT command you had when creating new users.
UTF-8 as default Charset
This is not yet the default charset coming with the server, but
utf8mb4 will be the main charset instead of
latin1, and the default collation will
utf8mb4_800_ci_ai. The plan is to do that before
Giving an …[Read more]
Disclaimer: this post takes into consideration that strict mode is enabled on the server
used to store strings.
VARCHAR stores varying length
CHAR always use the same exact size no matter
the size of the string. For example, CHAR(4) will always
store 4 bytes, whereas VARCHAR(4) will store up to 5
bytes. See documentation.
When we create a table like this one:
We put inside the parentheses the length of the field in
characters for the
VARCHAR field. However, the
maximum size in bytes of the field will depend on the
COLLATION of the table. You
can also specify a different collation for a column.
- latin1: 1 to 2 bytes per …
Last time I went to LaraconEU as in 2014 as speaker in the community track, it was my first international event ever speaking in english and I had jitters from it.
A lot a friends were made and it was nice to see all of them again this year.
What I also like about LaraconEU it is a Laravel conference that doesn’t talk always about Laravel, being a bit less insular than one would imagine.
Shawn McCool and his team made a great job this year and I was very honoured this year to be in the Track #1 (Blue Track).
The first round of applauses when I was introducing myself and saying this was my second Laracon made very much emotional and triggered something on my mind:
These people are there to soak in the knowledge you have to share, so give your best, and I confess I tried exactly that.
The venue was amazing, I don’t have a single complaint to …[Read more]
Different types of languages deal with this “value” in diverse
ways. You can have a more comprehensive list of what
NULL can mean on this
website. What I like to think about
along the lines of invalid, as if some sort of garbage
is stored there. It doesn’t mean it’s empty, it’s just mean that
something is there, and it has no value to you.
Both databases recommend using
\N to represent
NULL values where import or exporting of data is
When …[Read more]
It's almost a year old, but this post on the Pinterest engineering blog is really great advice: https://engineering.pinterest.com/blog/learn-stop-using-shiny-new-things-and-love-mysql
My favorite advice from there: "Keep it simple. No matter what technology you’re using, it will fail."
New MySQL version, YAY!
MySQL 5.7 is full of new features, like virtual columns, virtual indexes and JSON fields! But, it came with some changes to the default configuration. When running:
What I want to talk about is the
mode. This mode rejects queries where nonaggregated columns are
expected, but aren’t on the
GROUP BY or
HAVING clause. Before MySQL 5.7.5,
ONLY_FULL_GROUP_BY was disabled by default, now it
You know the drill…
This is a simple statement, people use it everywhere, it shouldn’t be that hard to use, right?
Given the following schema:
Suppose I want to list all users that commented on …[Read more]
Article on Information Age:
From obscurity to the mainstream, the journey of MySQL shows the power of the open source community to drive innovation. Read the full article here: http://goo.gl/bqFZPb
TEXT fields are a nightmare. For you and for your server. It is slow to retrieve, and if you are doing searches on it, be prepared, things are going to get bumpy.
If you use MySQL with a MyISAM engine, this may not be an issue
for you, you can create a
FULLTEXT index, your only
problem is if you want to add a new column, an alter table can
take forever, since MySQL creates a new table and copies the old
data to the new table. For those who uses MySQL with an InnoDB
engine, prepare because, you’ll have more issues. Indexes
FULLTEXT and if you do
need an index you must inform the length of it. It defeats the
purpose of you doing the search in that field.
The observation above is only true for MySQL 5.5
or below, since version 5.6 MySQL does support
FULLTEXT indexes on InnoDB – thanks Davey …