MySQL match against 0 result in MyISAM but works on InnoDB -

i have table

 create table `tbl` (   `id` bigint(20) not null,   `code` varchar(64) collate utf8mb4_unicode_ci default null ) engine=myisam default charset=utf8mb4 collate=utf8mb4_unicode_ci; alter table `tbl` add primary key (`id`); alter table `tbl` add fulltext key `code` (`code`);  insert `tbl` (`id`, `code`) values (1, '110.103'); 

and query

select code `tbl` (match (code) against ('110.103*' in boolean mode) )  

but there no result. idea?

first of all, fulltext indexes stores words. words seperated e.g. period - isn't letter, digit, underscore or single apostrophe. text consists of 2 words, "101" , "103".

the mysql fulltext index store words a minimum word length. myisam uses 4 default value ft_min_word_len, 3-digit "words" not included, while innodb uses 3 innodb_ft_min_token_size, why included. change these settings (and rebuild index), , both engines find same rows.

that being said: match (code) against ('110.103*' in boolean mode) still search words. find row contains "word" 110 or(!) word starting 103. can enforce have both words ('+110 +103*' in boolean mode), can in order. can enforce specific order if use against('"110 103"'), " not support * anymore.

a common trick store numbers underscore 110_103 (and search way), complete word. can e.g. adding code_search-column keep up-to-date using trigger (or define generated column), , search in column. if code can contain _ too, not distinguish between _ , . anymore, have add additional condition (... match (code_search) against (...) , code '...') or that).

but not sure if need fulltext search here. if column contains single code (and not text several seperate words, use case fulltext index), might want try where code '101.103%', where code '%101.103%' or where code '101.103%' or code '% 101.103%' depending on looking exactly. add (normal) index code this, , @ least first search faster fulltext search (apart fact will, in contrast fulltext search, give reqired result).

and although doubt case here: if looking floating point numbers, make life lot easier if can store them actual numbers in seperate column (or seperate table if data contains more 1 floating point number per row).