Splitting apart a comma separated list
Example-ish code

It's clear that you have anonymized the procedure code by replacing real names by example names. In the future, it is better to use your real object &amp; variable names, as someone may actually have things to say to improve your naming, which is one of the most important aspects to code clarity/readability. 



Structure of procedure

There are some really strange things about the way your procedure is structured. For one, the test string that it's meant to parse is hard-coded into the procedure code. 


/* This passes as well. */
DECLARE myList varchar(255) default ' ,, ,   1,2  ,3, 456 , 7 8 9 ABC ,,  ';



I feel sure that this is temporary, but if one of my colleague SQL developers handed that to me for a code review, I would tell them they need to go finish the code first so it's actually usable for any test case. So the string to parse should be an argument to the procedure...

CREATE PROCEDURE `sp_ParseCommaSeparatedString`(
  in p_commaSeparatedString varchar(255),
  in p_willBeUsedLater int(10) unsigned
)


And as such, you can just document your test cases in block comment with procedure calls. This also documents to a reasonable extent how the procedure is meant to be used.

/* Test Cases - PASSED
call sp_ParseCommaSeparatedString('');   --0 rows
call sp_ParseCommaSeparatedString(null); --0 rows
call sp_ParseCommaSeparatedString('1');  --1 row
call sp_ParseCommaSeparatedString('1,2');--2 rows
--Complex test case, 5 rows
call sp_ParseCommaSeparatedString(' ,, ,   1,2  ,3, 456 , 7 8 9 ABC ,,  ');
*/


Unused parameter

This is dead code, as the name indicates: in p_willBeUsedLater int(10) unsigned

It would be more beneficial to not add it in until it is ready, so that the stored procedure calls aren't unnecessarily confusing. You would have 2 options here which would be better. MySQL is a bit clunky for something like this, as far as SQL goes, but it can still be done fine. 

1) Document as a TODO

CREATE PROCEDURE `sp_ParseCommaSeparatedString`(
  in p_commaSeparatedString varchar(255)
)
  MODIFIES SQL DATA
myProc:begin

/* 
 * TODO: implement additional input param:
 *   in p_someSensiblyNamedNumber int(10) unsigned
 * This parameter will be used for [...]
 */


2) Provide a default argument

CREATE PROCEDURE `sp_ParseCommaSeparatedString`(
  in p_commaSeparatedString varchar(255),
  in p_someSensiblyNamedNumber int(10) unsigned
)
  MODIFIES SQL DATA
myProc:begin

IF p_someSensiblyNamedNumber IS NULL THEN 
  SET p_someSensiblyNamedNumber = 36;


Either will work fine and which is better really depends on what you are needing to do with it. From the code your presented, that parameter is not used for anything right now and it's not clear from what you named it what it is supposed to do, so... hard to say. 

Now we can clean up the top a bit.

DECLARE stringToParse varchar(255);
SET stringToParse = TRIM(p_commaSeparatedString);


Results table

At the moment, you are finding yourself having to delete the rows from the table before you call the procedure, which is not ideal at all and will lead to errors. Instead, do that in your procedure, either at the top when you start, or just before you start inserting values in it (in case the code prior to that takes long, this would mitigate the possibility of another process adding rows into the same table which this is running). 

Just check if there are any rows in it, if there are not just skip, and if there are, delete them. 

IF EXISTS (SELECT 1 FROM example) THEN
    DELETE FROM example;
END IF;

WHILE (length(myList) &gt; 0)
DO...




Overall approach

SQL clearly was not designed to parse strings of text like a more general language/domain could; if things are not in tables, rows and columns, they are much more difficult to manipulate with SQL. With that in mind, I would say your logic is probably about as good as it is going to get, while still maintaining readability. 

Perhaps consider adding a small amount of code comments in the conditionals in your last WHILE section so that the next person who has to look and/or debug this code (which may very well be your future self) will not have too much difficulty. 



Nitpicks


DELIMITER ;;



This would make more sense if you set the delimiter to something that looks less like the normal delimiter. I have most often seen used $$, // and || as delimiters. 


trim(substring(myList,LOCATE(',',myList)+1,length(myList)));



Try to get in the habit of spacing your operators, commas, etc. to make it easier to read. Also, you are using mixed capitalization of keywords, which just looks a bit messy. Pick one capitalization style and stick to it.

TRIM(SUBSTRING(myList, LOCATE(',', myList) + 1, LENGTH(myList)));