Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
Post History
This answers your questions, not what I suspect to be real issue. According to the specifications a VARCHAR(100) will need actual data stored length + 1. So, the actual size would have mattered if...
Answer
#1: Initial revision
by
Alexei
·
2020-11-22T08:28:01Z (over 3 years ago)
This answers your questions, not what I suspect to be real issue. According [to the specifications](https://dev.mysql.com/doc/refman/8.0/en/storage-requirements.html#data-types-storage-reqs-strings) **a VARCHAR(100) will need actual data stored length + 1**. So, the actual size would have mattered if you have used CHAR(100) instead: > The compact family of InnoDB row formats optimize storage for variable-length character sets. See COMPACT Row Format Storage Characteristics. Otherwise, M × w bytes, <= M <= 255, where w is the number of bytes required for the maximum-length character in the character set. I am not sure what happens if the procedures manipulate strings longer than the VARCHAR columns allow it. If these are silently truncated, the execution might fit in the memory, but the end result is not what you are expecting.